Re: Ambiguous syntax

[Rena <hyperhacker@...>]

On 2012-12-16 2:35 PM, "Coda Highland" <chighland@gmail.com> wrote:
>
> On Sun, Dec 16, 2012 at 11:08 AM, Sven Olsen <sven2718@gmail.com> wrote:
> >
> >> So, for very little cost, we could keep the 5.1 check in the parser, but
> >> only trigger it in cases where we're extending a primary _expression_ that's
> >> already a complete function call or table index.
> >
> >
> > Here's something that may be a better idea:  Only trigger the error once the
> > primary _expression_ reaches some threshold of complexity.  For example, 2+
> > function calls, one of which has its '(' at the start of a new line.  Then
> > you could error on cases like:
> >
> >   local a = t[k]
> >   (f or g)()
> >
> > but, only emit the error when you start parsing the second '('.
> >
> > Without backtracking, I don't think there's any way to guarantee that the
> > check won't sometimes be triggered by false positives.  But, I do think
> > keeping a little logic in the parser to check for particularly dangerous
> > formatting is sensible.
> >
> > -Sven
>
> Your example is too simple for my tastes. In fact, it seems the entire
> heuristic is wrong -- I would be more likely to pull this stunt
> BECAUSE the _expression_ is too complicated and thereby needs to be
> broken across lines. A case as simple as this example I almost
> certainly mean that I want (f or g)() to be evaluated as a separate
> statement, but:
>
> local a = module.factories[factoryType].create
>   (1, 2, 3,
>    4, 5, 6)
>
> seems like a much more likely thing in my coding style.
>
> (Then again, my coding style would put the ( after create and the ) on
> its own line -- by MY coding style I would be arguing that the
> ambiguous case should ALWAYS resolve to two statements. But I'm not
> advocating for forcing my style onto others -- I'm joining in the
> discussion on the assumption that there are people who USE this
> style.)
>
> Treated as a context-sensitive grammar instead of a context-free one,
> it would be theoretically possible to make the decision at run-time
> based on the value of the first _expression_, but this is a Bad Idea. So
> throw that one out too.
>
> An error based on ambiguous syntax with valid uses for either form is
> also a Bad Idea -- it means that BOTH use cases get hard-flagged as an
> error, which just makes for annoyance.
>
> This leaves two variations on one solution: choose one form as the
> canonical choice and offer syntax to explicitly select the other.
> Either always interpret it as two statements and either offer a
> line-extension character or force the use of attached braces, or
> always interpret it as one statement and offer a statement-separator
> character.
>
> Since Lua already had a statement separator character, it was a clear
> choice for PUC-Rio to make.
>
> It would be useful to have some sort of syntax check mode for the Lua
> parser that outputs warnings for ambiguous constructions without
> actually executing the code; you wouldn't use this for run-time code
> but as a testing step for the appropriate audience it would be useful.
>
> /s/ Adam
>

I always liked how 5.1 did it. I've run into the error before, and it's easily fixed by moving the bracket or adding a semicolon. I think without that warning it could be much harder to figure out what went wrong.