Re: x="abc":upper() v.s. x=("abc"):upper() patch

[delbu9c1@...]

To clarify this, I am addressing this because the (...) has an obvious ambiguity -- that of a function call vs a new statement. However, my code would not appear, especially to beginners, to have the potential to be a function call. It is a strange construct similar to that of using no tabulation in code.
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: delbu9c1@erau.edu

Date: Sat, 15 Aug 2009 23:34:29 
To: Lua list<lua@bazar2.conectiva.com.br>
Subject: Re: x="abc":upper() v.s. x=("abc"):upper() patch


It seems like you're advocating that the following be ambiguous, if I understand you correctly.

Foo = bar
"baz":quux()

That does not seem like a good idea to me... It would approach the point where semicolons are required all over the place. Personally I use semicolons all the time...but that's not the point.

Matt
Sent from my Verizon Wireless BlackBerry

-----Original Message-----
From: David Manura <dm.lua@math2.org>

Date: Sat, 15 Aug 2009 18:40:37 
To: Lua list<lua@bazar2.conectiva.com.br>
Subject: x="abc":upper() v.s. x=("abc"):upper() patch


Would there be any reason not to allow ("abc"):upper() to be rewritten
as "abc":upper() ?  One complication is that the syntax is ambiguous
if the function call is used as or could be interpreted as a
statement.  The following is twice ambiguous:

  x = lower
        "abc"   -- ambiguous
  "abc":foo()  -- ambiguous

We'd like to avoid adding ambiguous syntax.  However, it could be
argued that the above doesn't add a new class of ambiguous syntax but
rather makes that existing class more consistent.  The above is just
syntactic sugar for

  x = lower
        ("abc")   -- ambiguous
  ("abc"):foo()  -- ambiguous

which itself is just as ambiguous, even under Lua 5.1.  The new rule
enforced by the parser becomes "there can be no line break between
prefixexp and args".  This new rule, unlike the old one, is invariant
under any translation between the two syntax forms above.

A prototype of how this might be implemented is given in the attached
patch (lua-5.1-string-paren-patch).  There is also a related patch [1]
that avoids spurious ambiguous syntax errors when the expression
cannot be interpreted as a statement.

Part of the reason for suggesting this was to analogously allow things
like ({3,2,1}):map(f) to be rewritten as {3,2,1}:map(f).  Now, even if
that could give no syntax error, it would normally still give a
runtime error.  That would be avoided if we could automatically assign
a default metatable with __index to constructed tables [3,*].  Lua
doesn't do that, at least in part, because it interferes with using
tables as maps/sets, but this problem can be avoided under the
__methindex (a.k.a. __mcall) proposal [2], which allows ":" to be
treated differently from ".".

[1] http://lua-users.org/lists/lua-l/2009-01/msg00052.html
[2] http://lua-users.org/lists/lua-l/2009-06/msg00394.html
[3] http://lua-users.org/lists/lua-l/2003-12/msg00384.html
[*] I was thinking of also adding a new table metamethod that
     would process fields (including nils) passed to the table constructor