Re: expression parser change

["E. Toernig" <froese@...>]

Roberto Ierusalimschy wrote:
>
> > but also nifty constructs like
> > 
> >    "%d":format(42)
> >    { a, b, c }[i]
> 
> This creates more cases of ambiguous syntax:
> 
>   a = b + c
>   "%d":foo(42)
> 
> But they are all similar to what we already have with parentheres.

Right - and as I don't like those ambiguities at all I suggested
the second patch in the original posting:

   Only accept statement expressions that start with an identifier.[1]

That gets rid of them.  (That patch also added the identity function
to help writing arbitrary expression statements.)

> > Of course, it's 100% backwards compatible.
> 
> It is not...
> 
> The following chunk has the same meaning in 5.1 and 5.2 alpha,
> but gets a different meaning with this change:
> 
>   a = nil
>   (print or io.write)(a)

Ok, got me.  But IMHO that code should have never been parsed as
two statements.  It's illogical, fragile and hard to read.
Just see what happens if you change the nil to something else
like "b" or "2*(x+y)" or "foo()" ...

Make it

    a = nil
    Id(print or io.write)(a)

with Id being the identity function (function Id(...) return ... end)
and everything's fine.

Ciao, ET.


[1] I don't know the BNF grammar for non-consuming tokens - say it's
written as TOKEN(nc) - then the change is something like:

statement: for_statement
         | while_statement
         ...
-        | statement_expr
+        | TK_NAME(nc) statement_expr
+        | syntax-error