Luke Palmer wrote: > On Thu, 12 Sep 2002, Ken Fox wrote: > > Perl already needs infinite lookahead. > > Really? Where?
Indirect objects need infinite lookahead and they are in the core language. Hyper operators may need lookahead. Place holders may need lookahead. User defined rules will definitely need infinite lookahead. (Remember we are switching from LR to LL parsing. LL(1) parsing is not as powerful as LR(1), so Perl 6 will need lookahead even in places where Perl 5 doesn't.) > Computers don't like ambiguous grammars ... The "dangling else" problem is ambiguous. Every time you get a shift-reduce conflict in yacc, you have an ambiguous grammar. Computers don't care about ambiguous grammars, but some of the common tools (yacc) disambiguate whether we like it not. ;) 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. > 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.)) 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
