On 02/04/12 00:00, Joe Groff wrote:
>>
>> -private define noPrecBinaryOp;
>> -[OP]
>> -inline overload noPrecBinaryOp(forward a, #OP,forward ..args)
>> -    = forward a,OP,..noPrecBinaryOp(..args);
>> -[OP,T,U when BinaryOpDefined?(OP,T,U)]
>> -inline overload noPrecBinaryOp(forward a:T, #OP,forward b:U, forward ..args)
>> -    = forward ..noPrecBinaryOp(OP(a,b), ..args);
>> -[OP,T,U when integerEquals?(countValues(..CallOutputTypes(OP,T,U)),0)]
>> -inline overload noPrecBinaryOp(forward a:T,#OP,forward b:U, forward ..args)
>> -    {OP(a,b);}
>> -[OP,T,U when BinaryOpDefined?(OP,T,U)]
>> -inline overload noPrecBinaryOp(forward a:T,#OP,forward b:U)
>> -    = forward OP(a,b);
>> +overload binaryOp(..args) = ..args;
> On Sun, Apr 1, 2012 at 3:44 PM, agemogolk<reply+p-631168->
>>   Not convinced by the pipe idea you suggested for handling variadic
>> inputs to infix operators. I guess the issue is the evaluation of
>> operand expressions prior to passing the infix chain into infixOperator.
>> One solution could be to pass through the unmodified section of the AST
>> and handle in that in the library. However that seems impractical.
>>
>> I'm still concerned about compile times and that the
>> infix-/prefix-Operator setup is going to balloon into a full blown term
>> re-writing thing. Exposing/modifying  AST should probably be done from a
>> single point __AST__ or whatever.
> I had been thinking that an __AST__ operator and `eval` support for
> ASTs is ultimately the right way to go with this. But as you said,
> some cute potential uses of variadic arguments are probably not worth
> the effort; it's really just an accident of the desugaring that they
> happen to work.
>
>> So I'm wondering whether it would be better to move operator handling
>> back into the parser, use top level symbol definitions for custom
>> operators and use the afore mentioned Pratt parser to sort it out.  You
>> would still get the user defined ops/prec/assoc just tabulate operator
>> specs during parsing as well as processing symbol as usual i.e. define
>> (**)[LEFT,1000] or define (**, LEFT, 1000) or whatever.
>>
>> Or do you think the current approach can be sufficiently extended
>> without getting messy?
> Aside from the variadic arguments issue, are there any other
> outstanding issues with your current implementation? It seems like
> we're closing on a usable interface based on the current low-level
> interface.
>
> -Joe

Outstanding issues are:
     * variadic list operands (including multi-valued lists)
     * compilation performance
     * seperate handling of infix/prefix operators
     * repeated operators to variadic calls e.g. 
<code>1+2+3+4*5*6</code> evaluates as <code> (+)(1,2, (*)(4,5,6))</code> 
instead of <code> (+)((+)(1,2), (*)((*)(4,5),6)) </code>

Implementing anything that uses variadic lists brings up the same issue 
I had with mixing evaluation of infix & prefix operators - 
differentiating static operands from operators. The only thing making 
the current infix implementation work is (was!) the strict 
operand-operator-operand form. Making variadic list operands work would 
require an Operator? primitive which is difficult due to the possible 
definition of an operator via global aliases which is an issue we've 
discussed before.
For example using this type of operator definition <code>alias (**) = 
pow;</code> the infixOperator desuger will actually look like <code>2 ** 
3 --> infixOperator( 2, Static[pow], 2)</code> where 'pow' obviously 
isn't an operator symbol.

Although, I think if we have operators defined as symbols we really do 
need to have operator symbol introspection. Disallowing global alias 
definitions of operators is a solution, but not a good one as it would 
introduce an inconsistency in the 'operator is just a symbol' paradigm 
and <code>alias (**) = pow;</code> is pretty useful.

That restriction aside the simple solution to variadic list operands is 
to disallow them. However, it would be nice to be able to use 
multi-valued lists as operands.

An alternative is to pass them through with some kind of delimiter that 
can processed unambiguously, which I guess is the 'pipe' idea e.g.
<code> infixOperator( 1,  (+), <var_list> , 2, 3, </var_list> , (*), 
4)   -->  (+)(1, (*)( 2, 3, 4)) </code>

I think the best solution is to find a way of making Operator? possible.