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
