On Sun, Jan 18, 2009 at 10:57:26PM -0800, Mark Lentczner wrote:
> 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...
Caveat: The actual autogeneration of metaop tokens needs to be
refactored somewhat. Currently any constraints are enforced
at match-time, which doesn't help trim down the list of possible
tokens. The absence of a declarative framework induces various
distortions in how the rules are formulated currently.
> 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!)
Agreed.
> !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.
Changed to :returns<Bool> now.
> [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').
There maybe needs to be a restriction on "thunky" macro-operators.
> 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
> ?
The intent was to restrict any kind of recursion for something that must
be recognized by LTM, where recursion means revisiting the same metaop.
I'd like all other allowed compositions of metaops, though. However,
the LTM is not yet powerful enough to handle that many tokens.
> 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.
The intent is to allow these eventually.
> 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])
Things like >>>>+<<<< are disallowed because you can't use recursive
patterns in the LTM if it is to remain in the realm of regular
languages. [X>>+<<X] will eventually be allowed however. Maybe.
While that is not recursive on the metaops themselves, it is
recursive on the infixish rule. We'd have to recognize purely
delegative rules and not count those in the recursion elimination.
I actually had this in the lexer generator at one point, but it broke,
and I haven't gone back and fixed it. It does potentially generate
a huge number of tokens, so the LTM needs to get a bit more robust
in large sets of tokens before we can really support it.
> 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.
Again has to do with faking out the LTM pattern generator for now. Should
get better later.
Larry
