Re: Mixing operators and dot notation

["Alejandro R. Mosteo" <alejandro@mosteo.com>]

On 03/06/16 01:26, Randy Brukardt wrote:
> "Robert A Duff" <bobduff@TheWorld.com> wrote in message
> news:wccshwvgr8n.fsf@TheWorld.com...
>> "Alejandro R. Mosteo" <alejandro@mosteo.com> writes:
>>
>>> I'm trying to abuse Ada syntax for nefarious purposes and have arrived
>>                 ^^^^^ Probably an apt description.  ;-)

Since currently I'm using Ada only as a hobby, I mostly try bizarre 
things ;-)

>>> at something that looks inconsistent to me, but I fail to see if it is
>>                           ^^^^^^^^^^^^
>> Yes, the rules are inconsistent.

Ouch.

>>
>>> expected behavior or a bug. This is a self-contained example which is
>>> below.
>>
>>>     Op (1, 2).Method;  --  Fine
>>>
>>>     --  (1 & 2).Method;  --  Error: statement expected
>>
>> That's syntactically illegal; take a look at the BNF.
>
>> But you can say:
>>
>>    Nest.Object'Class'(1 & 2).Method;
>>
>> Ada makes a syntactic distinction between 'name' and 'expression',
>> which I think is unwise.  ARG has been chipping away at it over
>> the years.  Anyway, nowadays, a qualified_expression is a name,
>> so if you have an expression you want to use as a name, you can
>> just qualify it.
>
> True (for Ada 2012), but it probably defeats the purpose to do that. (If you
> have to know the full expanded names of everything, there's little value to
> prefix notation in the first place.)
>
> You also can write:
>
>      "&" (1, 2).Method
>
> which might defeat the purpose less. (Or not, not knowing the actual
> intent.)

Both defeat the purpose. I explain it below.

> Also to Bob's point, a type conversion always has been a name, so that:
>
>     Nest.Object'Class(1 & 2).Method;
>
> is syntactically legal in Ada 2005 as well, but it not resolve (the operand
> of a type conversion can't use the context in any way, so it depends on what
> & operators are visible as to whether this would work). This was the reason
> that we changed Ada 2012, since it is silly that type conversions would be
> allowed somewhere, but qualified expressions (which just confirm the type)
> would not be.

Yep, I've done this too, but it's again not practical in my current pursuit.

To give you the essence. I'm back to trying to get a minimal ReactiveX 
(http://reactivex.io)-like thing working. The gist is that you can chain 
many transformation operations:

SourceType.Generate_Data
    .Op1 (...)
    ...
    .OpN (...)
    .Endpoint (Operate_With_Resulting_Transformed_Data);

As long as the ops receive and emit the same type, I can do it with 
generics. But those are in the minority. Since they receive one type and 
emit another, I'm trying to find the most elegant Ada solution that 
keeps compile-time type checking if possible, and straight code flow 
(this is where parentheses in the solutions above don't work, since they 
create "boxes within boxes").

I'm pursuing several approaches: one is to use a tagged type with all 
operations (which is the Java approach), and marshalling of arguments 
via generics (which java doesn't need by having in-place instatiations). 
That's not too bad but duplicates code, in the sense that for each 
operation you need too pieces: the operation and the marshalling, but at 
least the library user writes her code using only her own types, which I 
like:

SourceType.Generate_Data
    .Op1 (FromXtoY.Transformer
       (User_FuncX'Access)) -- User_FuncX returns Y
    .Op2 (FromYtoZ.Transformer
       (User_FuncY'Access)) -- User FuncY returns Z
    .Endpoint (Z_Type.As_Z (Function'Access));

Of course with proper shorter names it looks better. However, checks are 
performed at run time.

Another idea was to use "&" instead of dot notation,

Stream := SourceType.Generate_Data &
    Type1.Op1(...) &
    Type2.Op2(...) &
    Type4.Endpoint (...);

having all needed "&" in scope. This possibly requires more "use type" 
clauses and I haven't tested it yet but I think it should work and be 
neater, having a "&" taking different left and right types.

Another way I was trying was the hybrid one that doesn't work: Using dot 
notation while there are no type changes, and & to cast to the new type 
only when needed. (I needed it to work even without parentheses.)

The root of the problem is in that, to keep code natural (and 
compile-time checks) I want to keep the user unaware of class-wide 
wrappers, and that involves generics. Once you have generic instances, 
you lose dot notation for transforming operations (since you need to 
somehow glue two types together, and the new operations are no longer 
primitive). (On this path, I have an idea involving two instantiations 
for each type being used, but I'm trying to avoid that for now). (Also I 
had a neat approach using elaboration-time instantiations but I collided 
with accessibility checks since I didn't want everything to be at 
library level.)

Anyway, I will keep playing and probably come back for criticism/ideas. 
It's possible I'm missing other options, of course, which are welcome. I 
will post my experimental repository once/if something takes shape.

Álex.