John Williams wrote:
Good point. Another one is: how does the meta_operator determine the
"identity value" for user-defined operators?
Does it have to? The definition of the identity value---BTW, I like
the term "neutral value" better because identity also is a relation
between two values---is that $x my_infix_op $neutral == $x.
So the generic implementation that copies surplus elements is correct
with respect to the resulting value. You shouldn't expect the operator
beeing called as many times as there are elements in the bigger data
structure, though. It's called only for positions where both structures
have actual values. But that is the same as short-circuiting && and ||.
And somewhat the reverse of authreading from junctive values.
I believe the fine points fall out like this:
@a >>+<< 1 # replicate
@a >>+<< (1) # replicate: (1) is still scalar
@a >>+<< [1] # extend: [1] is an array (and will auto-deref)
I think they fall out naturally from typing and dispatch. But note
that the » « operator has three args. I haven't made the &op a dispatch
selector. If the my_infix_op from above needs to handle neutral elements
by itself just tell the dispatcher by defining
&infix_circumfix_meta_operator:{'»','«'}:(List,List,&my_infix_op:) and
construct the neutral elements when one of the list runs out of elements.
I hope the syntax I used does what I want to express. Note that in
:(List,List,&my_infix_op:) the first two elements are types while
&my_infix_op is a sub value. In that sense my &op was actually wrong
but it was nice for wording my sentence. So the generic name should read
&infix_circumfix_meta_operator:{'»','«'}:(List,List:Code) or perhaps
&infix_circumfix_meta_operator:{'»','«'}:(List,List:&) if & is considered
as the code sigil. Hmm, then we could also have :(@,@:&) meaning the
same type spec?
BTW, starting from these type specs I come (back) to the suggestion of using
» « for hypering function calls and/or their arguments. Has that been decided?
I'm not sure if specialisation on values is covered by the :() syntax.
E.g. one could implement &infix:<*>:(0,Any) to return 0 without evaluating
the Any term at all! But this needs either lazy evaluation in the functional
paradigma or code morphing 'x() * y()' to '(($t = x()) != 0) ?? $t * y() :: 0'
or some such. On assembler level this morphing reduces to an additional
check of a register for zero. But I'm not sure if the type system and the
optimizer will be *that* strong in the near future ;)
Regards
--
TSa (Thomas Sandlaß)
