> BTW, there are some parser generators that handle > ambiguous grammars -- they either support backtracking, > infinite lookahead, or simultaneously parse all possible > derivations. In the case of the simultaneous parse, they > can actually return multiple parse trees and let the > code generator decide how to interpret things.
A la my very own Parse::Earley. But don't try to use the parse "graph" yet, as it is near impossible to traverse. > > But in Perl 5, C<if> is not a sub. > > ... > > Because subs have to work as expressions. > > In Perl 6 the difference between "sub" and "syntax" is > almost non-existant. Some subs will behave like built-in > syntax, some subs will behave like "normal" function > calls. (AFAIK, the only difference is that subs can not > provide lazy argument evaluation. Maybe the "is rx" > property eliminates even that? BTW, does anybody else > find "is rx" funny? "This is your argument. This is your > argument on drugs." (Rx is an abbreviation for drug > prescription in the U.S.)) Yeah, that's exactly why I said that. This discussion is getting rather stagnant, so I'll just back off and let the design team work all this out. > I think Perl 5's solution for handling "if" can be > applied to Perl 6 subs that look like syntax. It might > not be an improvement over Perl 5, but at least it's > no worse. > > A better solution may be to continue the parse until > we see if "for" is followed by a block. (That's really > hard to do with yacc, which might be why Perl 5 does > what it does.) > > - Ken Luke
