On Fri, Mar 18, 2005 at 04:06:21PM -0700, Luke Palmer wrote:
: Larry Wall writes:
: > %::{'&infix:<Y>'}, I suspect.
: 
: I suspect that's a bad idea.  What about &infix:{'<'}?

Well, one could go with &infix:«<» in that case, but yes, one could
always construct an operator that violates all the standard quotes.
I was thinking of it as just stealing the hash notation for another
purpose, but real hashes have the advantage of delimiting their keys
and values out of band.

: Perhaps there is a %infix: (in every appropriate scope) that holds
: anonymous symbol table references:
: 
:     %{%infix:{'Y'}}
: 
: And:
: 
:     %{%::{'%infix:'}{'Y'}}

Maybe it's just too early in the morning/week/year, but I don't
understand why you're putting the outer %{}.  It seems like

    %::{'%infix:'}{'Y'}

would be sufficient.  So should

    %::<%infix:><Y>

: We might make the table lookup smart enough to do the right thing, but
: then again, that may be a bad idea:
: 
:     keys %::;    # doesn't return &infix:<Y>

It'd presumably return '%infix:' as the key of one of its hash values,
which actually seems like it might be useful and efficient when it
happens you're trying to generate a list of infix operators.  As long
as the &infix: token prefix is syntactically smart enough to return a
reference to %::<%infix:>, the standard &infix:<Y> notation could even
be a hash lookup at run-time.  The main problem with that, of course,
is that things like operators are where you want the optimizer to
have as much information as possible at compile time.  We'd have to
have some way of representing to the compiler that it's okay to do
that lookup at compile time, and assume someone isn't changing the
symbol table out from under you.  Actually, it should probably assume
that by default, and the people who are wanting to doctor the symbol
table at run time should have to make the explicit representations.

Larry

Reply via email to