On Wed, Apr 06, 2005 at 12:32:37AM +0800, Autrijus Tang wrote:
: On Tue, Apr 05, 2005 at 08:24:42AM -0700, Larry Wall wrote:
: > That's why there's a statement_control:<if>, and there's a
: > statement_modifer:<if>, but there's no prefix:<if>. If you see
: > a statement modifier in the middle of an expression, it must be
: > interpreted as a statement modifier regardless of the context.
: > Statement modifiers are among the "most reserved" words in Perl.
:
: Aye. Is there an idea on how the two forms of `if` would be defined
: using plain Perl 6?
That's exactly what the syntactic category syntax is for, and why
parsing has to be done indirectly in terms of syntactic categories,
if you'll recall my message of some weeks ago on parser states.
: > So despite the fact that return parses like a list operator and
: > expects a term after it, the "if" is acting a bit like a semicolon.
:
: Got it. What if the user had defined a prefix form of `if`, though?
: Is it resolved using the precedence table?
Since the prefix syntactic category is only recognized where a term
is expected, I would guess that one of two things would happen.
Either you end up in a situation where a term expectation sees
prefix:<if> and operator expectation sees statement_modifier:<if>,
or both still see the statement_modifier:<if> and prefix:<if> is
effectively invisible. I can argue that one both ways, but I lean
toward the latter interpretation on the basis that someone could
really mess themselves up defining an "interface" function with a
sub if {...}
declaration. On the other hand, maybe we could allow the split
interpration if "if" is defined as a macro, which is less likely to
happen accidentally than "sub if". But that seems a bit hacky. I
think if people really want to override statement modifiers, they
should do it with an explicit grammar munge that elevates prefix:<foo>
to hide statement_modifier:<foo>. By default statement modifiers
are true reserved words, I think.
Larry
