On Thu, 12 Sep 2002, Ken Fox wrote: > Luke Palmer wrote: > > This requires infinite lookahead to parse. Nobody likes infinite > > lookahead grammars. > > Perl already needs infinite lookahead. Anyways, most people > don't care whether a grammar is ambiguous or not -- if we did, > natural human languages would look very different.
Really? Where? Computers don't like ambiguous grammars, because they don't know which to execute. Ambiguity is a feature in natural language, but not computer. Or you could make a language that selects a meaning randomly, but that just feels too much like INTERCAL :). > Perl 5 doesn't accept either of these loops: > > if ($_) { print "$_\n" } for (qw(1 0)); > print "$_\n" if ($_) for (qw(1 0)); Indeed. But in Perl 5, C<if> is not a sub. This is valid: eval { print "foo\n" } for @ar; And I've been hearing that you can do this in Perl 6: eval { print "foo\n" } (of course with C<try> instead, but this is more illustrative) And _that_ is a terminated statement. But it's also an expression. This is problematic, because of the ambiguity presented earlier. > The code must be written as: > > for (qw(1 0)) { > print "$_\n" if ($_) > } > > Why won't a similar solution work for user-defined syntax in > Perl 6? (It would be no worse than Perl 5...) Because subs have to work as expressions. It would all be well and good if you had to give an C<if>-like sub a special property: sub perhaps ($cond, $prob, &code) is statement {...} But somehow that doesn't seem very elegant. Luke