 |
lua-l archive |
|
|
||
|
On 2012-09-16 5:44 PM, "Sven Olsen" <sven2718@gmail.com> wrote:
>
> Hi list,
>
> So I've been mulling what Luiz Henrique told me about if-then statements -- namely, that if we make the "then" token optional, it will encourage bugs, as:
>
> if c then (f)(2) end
>
> is parsed quite differently than:
>
> if c (f)(2) end
>
> But over the last few months I've noticed that similar issues have a way of cropping up in other parts of my lua code.
>
> For example, I often find myself writing lines like this one:
>
> if a.myfun then a.myfun() end
>
> Eventually I discovered that it can be more concise to write:
>
> (a.myfun or _nullop)()
>
> And that seemed like a handy pattern, until I tried it after closing another function call:
>
> local a = new_a(args)
> (a.initfun or _nullop)()
>
> Which of course fails terribly.
>
> So now I'm starting to wonder if my lua parser might benefit from a little newline sensitivity. Some poking around in the source reveals that it's fairly easy to modify primaryexp() so that it will return early in the case that we encounter a '(' that's also the first token of a new line. After making that small change:
>
> a(2) (x)(3)
>
> compiles to a single primaryexp(), while
>
> a(2)
> (x)(3)
>
> compiles as two consecutive statements.
>
> My sense is that this is a good change -- as it means I'm less likely to run into obscure bugs anytime I want to write a statement that starts with a '('. As long as the new statement starts on a new line, I don't need to worry about whether or not whatever came before it ended with a ')'.
>
> I'm curious what the larger lua community thinks of it though. Do the rest of you often write statements that start with '('? If so, how do you stop them from getting appended onto the ends of prior function calls? Semicolons? Are there drawbacks to adding newline sensitivity to primaryexp() that I'm missing?
>
> If other people are interested in the diff, I can try posting it on the power patch page.
>
> Thanks,
>
> -Sven
I thought the parser warned about such ambiguous statements as in your example, and your suggestion allows for exactly the kind of ambiguity it was intended to disallow?
Probably a better method is to make your intent explicit with a semicolon:
f(a);
(g or h)(b)
Not depending on whitespace also means your code doesn't break if someone decides to compact it all into a string with spaces removed.