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

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

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

David Manura
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

lua-5.1-string-paren-patch (3K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

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

Matthew Paul Del Buono
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 <[hidden email]>

Date: Sat, 15 Aug 2009 18:40:37
To: Lua list<[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

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

Matthew Paul Del Buono
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: [hidden email]

Date: Sat, 15 Aug 2009 23:34:29
To: Lua list<[hidden email]>
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 <[hidden email]>

Date: Sat, 15 Aug 2009 18:40:37
To: Lua list<[hidden email]>
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

Reply | Threaded
Open this post in threaded view
|

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

David Manura
On Sat, Aug 15, 2009 at 7:39 PM, delbu9c1 wrote:
> On Sat, Aug 15, 2009 at 7:34 PM, delbu9c1 wrote:
>> It seems like you're advocating that the following be ambiguous, if I understand you correctly.
>>
>> Foo = bar
>> "baz":quux()

Yes, that would give an "ambiguous syntax" error under the new
proposal, whereas currently it is interpreted as Foo =
bar("baz"):quux(); .  Alternatives without semicolons include

  Foo = bar "baz"
                 :quux()

Some discussion on semicolons was in [4].

[4] http://lua-users.org/lists/lua-l/2009-02/msg00360.html
Reply | Threaded
Open this post in threaded view
|

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

Peter Cawley
In reply to this post by David Manura
On Sat, Aug 15, 2009 at 11:40 PM, David Manura<[hidden email]> wrote:
> The new rule
> enforced by the parser becomes "there can be no line break between
> prefixexp and args".

Given that:
functioncall ::=  prefixexp args | prefixexp `:´ Name args

In the latter case, is the rule "no line break between prefixexp and
args", or is it "no line break between Name and args"?
Personally, I often find myself using this style of indenting in some
situations:
factory_function(...)
  :modifier_method_1(...)
  :modifier_method_2(...)
  -- etc.

This places a newline between the prefixexp and the args, so if this
no longer works, it would cause me problems.
Reply | Threaded
Open this post in threaded view
|

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

Matthew Paul Del Buono
In reply to this post by David Manura
Sorry for being unclear. I feel that this would make more sense as two statements than it would as a single (complex) statement.
------Original Message------
From: David Manura
Sender: [hidden email]
To: Lua list
ReplyTo: Lua list
Subject: Re: x="abc":upper() v.s. x=("abc"):upper() patch
Sent: Aug 15, 2009 6:50 PM

On Sat, Aug 15, 2009 at 7:39 PM, delbu9c1 wrote:
> On Sat, Aug 15, 2009 at 7:34 PM, delbu9c1 wrote:
>> It seems like you're advocating that the following be ambiguous, if I understand you correctly.
>>
>> Foo = bar
>> "baz":quux()

Yes, that would give an "ambiguous syntax" error under the new
proposal, whereas currently it is interpreted as Foo =
bar("baz"):quux(); .  Alternatives without semicolons include

  Foo = bar "baz"
                 :quux()

Some discussion on semicolons was in [4].

[4] http://lua-users.org/lists/lua-l/2009-02/msg00360.html


Sent from my Verizon Wireless BlackBerry
Reply | Threaded
Open this post in threaded view
|

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

David Manura
In reply to this post by Peter Cawley
On Sat, Aug 15, 2009 at 10:11 PM, Peter Cawley wrote:

> On Sat, Aug 15, 2009 at 11:40 PM, David Manura wrote:
>> The new rule
>> enforced by the parser becomes "there can be no line break between
>> prefixexp and args".
>
> Given that:
> functioncall ::=  prefixexp args | prefixexp `:´ Name args
>
> In the latter case, is the rule "no line break between prefixexp and
> args", or is it "no line break between Name and args"?
> ....
> factory_function(...)
>  :modifier_method_1(...)

In that case there would be no rule because there is no ambiguity.
"factory_function(...) :", "factory_function(...) : name", and
":modifier_method_1(...)" cannot form valid statements.

Now, there was a proposal, related to [2] above, that would cause
"a:b" to be equivalent to "(function(...) return a(b, ...) end)".
Under that proposal, "factory_function(...) : name" _could_ be a
suffix of a valid statement.  The first rule should then be simplified
to "no line break before args".  Even without the "a:b" proposal, we
could still choose to make that simplification.