Re: Ambiguous syntax

[Coda Highland <chighland@...>]

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