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

Reply via email to