I was looking through STD.pm at the parsing of metaops. I was
exploring to see if the legal metaops for a given operator could be
notated on the operator chart. What I found was some oddness...
op= (infix_postfix_meta_operator:sym<=>)
----------------------------------------
The internal op is restricted to be not :assoc('chain') and
not :assoc('non')... But, the various precedence groupings have a
property, :assign on them that is never used. Yet, this property seem
like just the thing. To my eye, :assign seems like the right set of
operators that are expected to be used here. The current test is too
liberal, allowing things like ,= and ==>>= (gasp!)
!op (infix_prefix_meta_operator:sym<!>)
---------------------------------------
The internal op is restricted to be :assoc('chain'), or not have a
default :assoc and be :bool. This seems overly defined: The only
operators with :assoc('chain') have :bool. Like above, I think the
internal op should be restricted on the :bool property alone.
[op] (prefix_circumfix_meta_operator.reduce)
--------------------------------------------
This internal op is restricted to not have :assoc('non') nor be at the
same precedence level as %conditional. That later test strikes me as
strange. The restriction should be not having :assoc('chain')
nor :assoc('non').
Now - the classes of what can be applied to what, especially
considering other metaops, is a bit tangled:
>>op -- op can be any >>op, postfix, dotty, privop, or postcircumfix
the later is odd: what could >>(...) mean?
op<< -- op can be any prefix, a [op], or another <<op
I suppose these multiply applied ops might be useful? op<<<< and
>>>>op ?
op=, !op, >>op<< -- op can only be a (simple) infix operator
[op], XopX -- op can an infix, or !op or XopX or >>op<<
or, put another way, any simple or complex infix op, except op=
I understand why op= and !op have highly restricted internal op sets.
But why should >>op<< be so restricted as well? It means that >><=<<
and >>~~<< are legal, but >>!<=<< and >>!~~<< are not.
And, if the prefix and postfix hyper metaops can be nested... then why
not the infix: >>>>+<<<< anybody? (Not, mind you, that *I* would
advocate for them, or such exotic beasts as [X>>+<<X])
Lastly, the token for [x] (prefix_circumfix_meta_operator.reduce) has
an oddity that it allows an optional trailing << (acutally, only the
Unicode version of that!). I'm not sure why the prefix hyper metaop is
parsed here... especially since the code for token PRE clearly parses
this construction.
- Mark
