On Tue, Apr 05, 2005 at 09:22:29PM +0800, Autrijus Tang wrote:
: On Mon, Apr 04, 2005 at 09:01:20PM -0400, Stevan Little wrote:
: > eval 'sub foobar { return if 1; }';
:
: I've fixed everything except this. I'm not exactly sure how the postfix
: form of "if" is supposed to work here, because the first thing the
: parser tries is to parse it as return(if(1)), as a valid expression itself.
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.
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.
If you want to embed a statement control inside an expression, you
have to use "do". We're thinking about allowing "do" without curlies
before any statement_control so that you could say
$x = do if $x { $y } else { $z }
But to make that work we'd have to give a different name to do-FILE
(which we're going to do anyway, so that's not a problem). And that
gives us a way to write the rather useful
$x = do given $x {
when 0 { 'a' }
when 1 { 'b' }
when 2 { 'c' }
default { '?' }
}
I expect general do-EXPR is disallowed. It's only bare blocks and
other statement beginnings that can follow "do". But that includes labels,
so you can say things like:
$x = do LINE: loop {
...
next LINE;
...
}
which there's no way to say in Perl 5 without do-{}.
: As Perl6 parsing is supposed to require no lookaheads, I wonder how
: we are to tackle this. Ideas?
One-token lookahead is fine. It's the arbitrarily long lookahead we're
trying to avoid. Or to put it the other way around, if you have to
backtrack, you've got an error, so use the backtracking capability
to try to give a good error message rather than trying to guess what
they mean. You can backtrack and continue parsing, but only to try
to determine what alternate choice might have made it come out better,
so you can give the befuddled user an intelligent "Did you mean..." hint.
Larry
