Some enhancements in table initializations

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

Some enhancements in table initializations

Nilson
Hi everybody,

I would like to request comments to some table enhancements below.
I apologize in advance if these propositions were already posted. I'm
new on this forum and couldn't search the previous messages.

--------------------------
Proposition 1. Make the separator optional in table initialization

Motivation:

It seems that all the syntactic sugar implemented in Lua aims to
improve the legibility and perhaps reduce the typing effort.

As the separator (;) is optional between statements, in some
situations the required separator in table initializations seems to be
a annoying alien stuff.

examples:
 { 1, 2, 3, 4, 5 }  =>    { 1 2 3 4 5 }
 { 0, 1, 1, 0, 1, 1 }  => { 0 1 1 0 1 1 }

function_variable { 'name'
   item1
   item2
   item3
}

while flag do
 item1
 item2
 item3
end

Requires:

CHANGE>  fieldlist ::= field {fieldsep field} [fieldsep]

TO>      fieldlist ::= field { [fieldsep] field} [fieldsep]

The compiler seems to be read to accept the change, because the execution of

local t = { 1+2+3 , 4+5    6+7 } generates an error: '}' expected near 6

--------------------------
Proposition 2. Extending the function name syntactic sugar to tables.

For example:

local function name() end       is equivalent to          local name =
function() end
and
local var = function name() end  generates a error

So, in table initialization, the construction:

local t = {  function name() end }

could be equivalent to

local t = { name = function() end }

and

local t = {  field = function name() end }

also should generate a error


--------------------------

Proposition 3: Unquoted strings constants: Define a string constant
without use of enclosing quotation marks - perhaps only in table
initializations.

This can be done using 2 approaches:

a) The simplest approach is define a single word string using a prefix
like a . (period) or \ (backslash) or any other light-weight
fast-typing symbol.

For example:

countries = { "US", "BR", "CA", "RU", "FR" }  => { .US, .BR, .CA, .RU, .FR }
countries = { "US", "BR", "CA", "RU", "FR" }  => { \US, \BR, \CA, \RU, \FR }

Using 1 and 3 together:

countries = { "US", "BR", "CA", "RU", "FR" }  => { .US  .BR  .CA  .RU  .FR }
colors = { "red", "green", "blue", "yellow", "black" }  => { .red
.green .blue .yellow .black }

The period could generate a scan error is  "US".."Tx" => .US...TX, but
it will be easily  solved using a with a space.

b) The complex and may be unfeasible approach is that:
Today, every syntactic element Name is evaluated as a expression and
if there is no entry in environment table with Name, Lua returns nil.

Well, the idea is: in table initializations, when the compiler uses
the production field ::= exp and the exp is a single Name
and Lua could not find a value, it will return the lexical element
Name as a string.

field ::= `[´ exp `]´ `=´ exp | Name `=´ exp | exp

OK,  it's may not be an excellent solution but the effect would be
great. For example:

{ "US", "BR", "CA", "RU", "FR" }  => { US, BR, CA, RU, FR }

Using 1 and 3 together:

countries = { "US", "BR", "CA", "RU", "FR" }  => { US  BR  CA  RU  FR }
colors = { "red", "green", "blue", "yellow", "black" }  => { red green
blue yellow black }

Well, That´s it.

--
Nilson

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
On Mon, Sep 20, 2010 at 8:29 PM, Nilson <[hidden email]> wrote:
> Proposition 1. Make the separator optional in table initialization
> Proposition 2. Extending the function name syntactic sugar to tables.

If they're doable, I like these two a lot.

> Proposition 3: Unquoted strings constants
>
> [snip]
>
> Well, the idea is: in table initializations, when the compiler uses
> the production field ::= exp and the exp is a single Name
> and Lua could not find a value, it will return the lexical element
> Name as a string.

Not something I'd really like, personally. Besides, you can do this
yourself with a metatable on _G (or whatever the current environment
table is) with an __index method that returns the key itself.

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

David Manura
On Mon, Sep 20, 2010 at 11:53 PM, Jonathan Castello <[hidden email]> wrote:
> On Mon, Sep 20, 2010 at 8:29 PM, Nilson <[hidden email]> wrote:
>> Proposition 1. Make the separator optional in table initialization
>> Proposition 2. Extending the function name syntactic sugar to tables.
>
> If they're doable, I like these two a lot.

There have been proposals for these before:

  http://lua-users.org/lists/lua-l/2003-02/msg00405.html
  http://lua-users.org/lists/lua-l/2010-01/msg01405.html

  http://lua-users.org/lists/lua-l/2008-02/msg00830.html
  http://lua-users.org/lists/lua-l/2010-08/msg00569.html

And personally, I've wanted something like Proposition 1.  Lisp and
CMake languages allow this simpler syntax.  The major problem it poses
in Lua is that Lua expressions without a commas between them can too
easily run together.  {a "" {}} is valid in Lua 5.1, for example.  The
problem also occurs with statements without semicolons between them
("ambiguous syntax" error) but with a much lower frequency.

You can simulate a Perl-like "qw" quote operator though:

  -- like http://perldoc.perl.org/perlop.html#Quote-Like-Operators
  local function qw(s)
    local t = {}
    for x in s:gmatch("%S+") do
      t[#t+1] = x
    end
    return t
  end

  t = qw[[ foo  bar  baz ]]

Unfortunately, you can't easily embed variables, particularly
lexicals, inside these strings.  That's a common problem, and more
ideally you'd want Lua to expand qw at the macro/lexical processing
stage rather than at run-time:

  http://lua-users.org/wiki/StringInterpolation

>> Proposition 3: Unquoted strings constants

See qw above.

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
In reply to this post by Nilson
While not exactly about table initializations, one thing I've
occasionally wanted was to be able to implicitly index the current
environment. In a table you can do {[a + b] = c}, but it would be nice
to be able to do [a + b] = c as a normal statement. Likewise with
accessing: x = [y].

Obviously you can just use _G (or _ENV in 5.2), but I'm not really a
big fan of "special" variables. I -think- that, given this
environmental indexing syntax, the _G identifier wouldn't even be
necessary unless you were doing something "unusual" like giving it a
metatable or saving it to another variable, in which case you could
just use getfenv().

Just something I figured I'd throw out there. Maybe a power patch is possible?
~Jonathan

On Mon, Sep 20, 2010 at 8:29 PM, Nilson <[hidden email]> wrote:

> Hi everybody,
>
> I would like to request comments to some table enhancements below.
> I apologize in advance if these propositions were already posted. I'm
> new on this forum and couldn't search the previous messages.
>
> --------------------------
> Proposition 1. Make the separator optional in table initialization
>
> Motivation:
>
> It seems that all the syntactic sugar implemented in Lua aims to
> improve the legibility and perhaps reduce the typing effort.
>
> As the separator (;) is optional between statements, in some
> situations the required separator in table initializations seems to be
> a annoying alien stuff.
>
> examples:
>  { 1, 2, 3, 4, 5 }  =>    { 1 2 3 4 5 }
>  { 0, 1, 1, 0, 1, 1 }  => { 0 1 1 0 1 1 }
>
> function_variable { 'name'
>    item1
>    item2
>    item3
> }
>
> while flag do
>  item1
>  item2
>  item3
> end
>
> Requires:
>
> CHANGE>  fieldlist ::= field {fieldsep field} [fieldsep]
>
> TO>      fieldlist ::= field { [fieldsep] field} [fieldsep]
>
> The compiler seems to be read to accept the change, because the execution of
>
> local t = { 1+2+3 , 4+5    6+7 } generates an error: '}' expected near 6
>
> --------------------------
> Proposition 2. Extending the function name syntactic sugar to tables.
>
> For example:
>
> local function name() end       is equivalent to          local name =
> function() end
> and
> local var = function name() end  generates a error
>
> So, in table initialization, the construction:
>
> local t = {  function name() end }
>
> could be equivalent to
>
> local t = { name = function() end }
>
> and
>
> local t = {  field = function name() end }
>
> also should generate a error
>
>
> --------------------------
>
> Proposition 3: Unquoted strings constants: Define a string constant
> without use of enclosing quotation marks - perhaps only in table
> initializations.
>
> This can be done using 2 approaches:
>
> a) The simplest approach is define a single word string using a prefix
> like a . (period) or \ (backslash) or any other light-weight
> fast-typing symbol.
>
> For example:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { .US, .BR, .CA, .RU, .FR }
> countries = { "US", "BR", "CA", "RU", "FR" }  => { \US, \BR, \CA, \RU, \FR }
>
> Using 1 and 3 together:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { .US  .BR  .CA  .RU  .FR }
> colors = { "red", "green", "blue", "yellow", "black" }  => { .red
> .green .blue .yellow .black }
>
> The period could generate a scan error is  "US".."Tx" => .US...TX, but
> it will be easily  solved using a with a space.
>
> b) The complex and may be unfeasible approach is that:
> Today, every syntactic element Name is evaluated as a expression and
> if there is no entry in environment table with Name, Lua returns nil.
>
> Well, the idea is: in table initializations, when the compiler uses
> the production field ::= exp and the exp is a single Name
> and Lua could not find a value, it will return the lexical element
> Name as a string.
>
> field ::= `[´ exp `]´ `=´ exp | Name `=´ exp | exp
>
> OK,  it's may not be an excellent solution but the effect would be
> great. For example:
>
> { "US", "BR", "CA", "RU", "FR" }  => { US, BR, CA, RU, FR }
>
> Using 1 and 3 together:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { US  BR  CA  RU  FR }
> colors = { "red", "green", "blue", "yellow", "black" }  => { red green
> blue yellow black }
>
> Well, That´s it.
>
> --
> Nilson
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Geoff Leyland
On 21/09/2010, at 6:37 PM, Jonathan Castello wrote:

> While not exactly about table initializations, one thing I've
> occasionally wanted was to be able to implicitly index the current
> environment. In a table you can do {[a + b] = c}, but it would be nice
> to be able to do [a + b] = c as a normal statement. Likewise with
> accessing: x = [y].


Wouldn't that cause ambiguous syntax problems?   Would "a = b [c]:d()" be one or two statements?

Cheers,
Geoff


Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
On Mon, Sep 20, 2010 at 11:44 PM, Geoff Leyland
<[hidden email]> wrote:

> On 21/09/2010, at 6:37 PM, Jonathan Castello wrote:
>
>> While not exactly about table initializations, one thing I've
>> occasionally wanted was to be able to implicitly index the current
>> environment. In a table you can do {[a + b] = c}, but it would be nice
>> to be able to do [a + b] = c as a normal statement. Likewise with
>> accessing: x = [y].
>
>
> Wouldn't that cause ambiguous syntax problems?   Would "a = b [c]:d()" be one or two statements?

I'm not sure how it could be construed in any other way than "a =
(b[c]):d()" in that context. Were you supposing that 'b' might be a
function? As far as I recall, functions can only accept a string
literal or a table literal as an argument without requiring
parentheses, so "b t[d]" is already syntactically invalid.

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
On Mon, Sep 20, 2010 at 11:52 PM, Jonathan Castello <[hidden email]> wrote:

> On Mon, Sep 20, 2010 at 11:44 PM, Geoff Leyland
> <[hidden email]> wrote:
>> On 21/09/2010, at 6:37 PM, Jonathan Castello wrote:
>>
>>> While not exactly about table initializations, one thing I've
>>> occasionally wanted was to be able to implicitly index the current
>>> environment. In a table you can do {[a + b] = c}, but it would be nice
>>> to be able to do [a + b] = c as a normal statement. Likewise with
>>> accessing: x = [y].
>>
>>
>> Wouldn't that cause ambiguous syntax problems?   Would "a = b [c]:d()" be one or two statements?
>
> I'm not sure how it could be construed in any other way than "a =
> (b[c]):d()" in that context. Were you supposing that 'b' might be a
> function? As far as I recall, functions can only accept a string
> literal or a table literal as an argument without requiring
> parentheses, so "b t[d]" is already syntactically invalid.
>
> ~Jonathan
>

Nevermind, I misunderstood what you meant by "statements". You mean it
could be interpreted as "a = b; [c]:d()"? That's a good point, I guess
there's no getting around that one.

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Geoff Leyland
On 21/09/2010, at 6:56 PM, Jonathan Castello wrote:

> On Mon, Sep 20, 2010 at 11:52 PM, Jonathan Castello <[hidden email]> wrote:
>> On Mon, Sep 20, 2010 at 11:44 PM, Geoff Leyland
>> <[hidden email]> wrote:
>>> On 21/09/2010, at 6:37 PM, Jonathan Castello wrote:
>>>
>>>> While not exactly about table initializations, one thing I've
>>>> occasionally wanted was to be able to implicitly index the current
>>>> environment. In a table you can do {[a + b] = c}, but it would be nice
>>>> to be able to do [a + b] = c as a normal statement. Likewise with
>>>> accessing: x = [y].
>>>
>>>
>>> Wouldn't that cause ambiguous syntax problems?   Would "a = b [c]:d()" be one or two statements?
>>
>> I'm not sure how it could be construed in any other way than "a =
>> (b[c]):d()" in that context. Were you supposing that 'b' might be a
>> function? As far as I recall, functions can only accept a string
>> literal or a table literal as an argument without requiring
>> parentheses, so "b t[d]" is already syntactically invalid.
>>
>> ~Jonathan
>>
>
> Nevermind, I misunderstood what you meant by "statements". You mean it
> could be interpreted as "a = b; [c]:d()"? That's a good point, I guess
> there's no getting around that one.

Yep, I was just writing a reply to that effect.  Apologies for not being clearer!

Cheers,
Geoff
Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
On Mon, Sep 20, 2010 at 11:58 PM, Geoff Leyland
<[hidden email]> wrote:
> Yep, I was just writing a reply to that effect.  Apologies for not being clearer!

No problem. In retrospect I think that was a terribly
un-thought-through suggestion, and I'm sorry I wasted readers' time on
it. :S

~Jonathan

Reply | Threaded
Open this post in threaded view
|

RE: Some enhancements in table initializations

Benoit Germain
In reply to this post by Jonathan Castello-2
> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]]
> De la part de Jonathan Castello
> Envoyé : mardi 21 septembre 2010 08:56
> À : Lua mailing list
> Objet : Re: Some enhancements in table initializations
>
> Nevermind, I misunderstood what you meant by "statements". You mean it
> could be interpreted as "a = b; [c]:d()"? That's a good point, I guess
> there's no getting around that one.

I can't help thinking that all these "this particular case could be interpreted as" we see each time some enhancement proposal comes up could be easily solved by having a mandatory  semicolon statement separator. This is not to say that all proposed enhancements should be thrown into the language, but it is a bit disappointing that some interesting propositions are abandoned out of hand because of this. So, I wonder whether this "historical quirk" of the language is worth keeping around, and for what reason? I understand that migrating the existing code might be painful, but I think that inconvenience could be much alleviated by some automated script. Coming from a C/C++ background, I wouldn't balk at the idea of using ; everywhere (which I don't do currently), but maybe others have a different opinion on the subject?


Benoit.

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Juris Kalnins
In reply to this post by Jonathan Castello-2
> Nevermind, I misunderstood what you meant by "statements". You mean it
> could be interpreted as "a = b; [c]:d()"? That's a good point, I guess
> there's no getting around that one.

If there was a simple rule to the effect that "if sequence of statements
can be interpreted as a single statement, then it is a single statement",
there would be no ambiguity.

I wish there was something similar to that stated in the docs, it
would give the language more solid feel, even if not changing anything.
Currently, figuring out how exactly Lua grammar is not ambiguous and
why one can omit ';' is actually quite a puzzle.

In a recent discussion it was mentioned about change in 5.2work3 that  
parses
f(x)
(y)(z)
as a single statement, instead of raising parse error. Is there any other
case left where Lua doesn't follow such rule?


Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
In reply to this post by Benoit Germain
On Tue, Sep 21, 2010 at 12:48 AM, Benoit Germain <[hidden email]> wrote:
> <snip> ... maybe others have a different opinion on the subject?

Personally, I favor Ruby's approach, which I believe uses newlines as
an effective syntactic hint to determine what your intent probably
was. It has optional semicolons, which you generally need to use if
you want to squish two statements onto one line (since as mentioned,
newlines are used as hints).

In most languages I've seen, it's uncommon to put multiple stand-alone
statements on the same line. Why use a semicolon where a newline would
do?

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

jgiors
In reply to this post by Nilson
> -------- Original Message --------
> Date: Tue, 21 Sep 2010 00:29:40 -0300
> From: Nilson <[hidden email]>
> Subject: Some enhancements in table initializations
> To: [hidden email]
> Message-ID:
> <AANLkTikAbFVKYs+hgsKKvFNTo2WHNNnA22=[hidden email]>
> Content-Type: text/plain; charset=ISO-8859-1
>
> Hi everybody,
>
> I would like to request comments to some table enhancements below.
> I apologize in advance if these propositions were already posted. I'm
> new on this forum and couldn't search the previous messages.
>
> --------------------------
> Proposition 1. Make the separator optional in table initialization
>
> Motivation:
>
> It seems that all the syntactic sugar implemented in Lua aims to
> improve the legibility and perhaps reduce the typing effort.
>
> As the separator (;) is optional between statements, in some
> situations the required separator in table initializations seems to be
> a annoying alien stuff.
>
> examples:
>  { 1, 2, 3, 4, 5 }  =>    { 1 2 3 4 5 }
>  { 0, 1, 1, 0, 1, 1 }  => { 0 1 1 0 1 1 }
>
> function_variable { 'name'
>    item1
>    item2
>    item3
> }
>
> while flag do
>  item1
>  item2
>  item3
> end
>
> Requires:
>
> CHANGE>  fieldlist ::= field {fieldsep field} [fieldsep]
>
> TO>      fieldlist ::= field { [fieldsep] field} [fieldsep]
>
> The compiler seems to be read to accept the change, because the execution of
>
> local t = { 1+2+3 , 4+5    6+7 } generates an error: '}' expected near 6
>
> --------------------------
> Proposition 2. Extending the function name syntactic sugar to tables.
>
> For example:
>
> local function name() end       is equivalent to          local name =
> function() end
> and
> local var = function name() end  generates a error
>
> So, in table initialization, the construction:
>
> local t = {  function name() end }
>
> could be equivalent to
>
> local t = { name = function() end }
>
> and
>
> local t = {  field = function name() end }
>
> also should generate a error
>
>
> --------------------------
>
> Proposition 3: Unquoted strings constants: Define a string constant
> without use of enclosing quotation marks - perhaps only in table
> initializations.
>
> This can be done using 2 approaches:
>
> a) The simplest approach is define a single word string using a prefix
> like a . (period) or \ (backslash) or any other light-weight
> fast-typing symbol.
>
> For example:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { .US, .BR, .CA, .RU, .FR }
> countries = { "US", "BR", "CA", "RU", "FR" }  => { \US, \BR, \CA, \RU, \FR }
>
> Using 1 and 3 together:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { .US  .BR  .CA  .RU  .FR }
> colors = { "red", "green", "blue", "yellow", "black" }  => { .red
> .green .blue .yellow .black }
>
> The period could generate a scan error is  "US".."Tx" => .US...TX, but
> it will be easily  solved using a with a space.
>
> b) The complex and may be unfeasible approach is that:
> Today, every syntactic element Name is evaluated as a expression and
> if there is no entry in environment table with Name, Lua returns nil.
>
> Well, the idea is: in table initializations, when the compiler uses
> the production field ::= exp and the exp is a single Name
> and Lua could not find a value, it will return the lexical element
> Name as a string.
>
> field ::= `[´ exp `]´ `=´ exp | Name `=´ exp | exp
>
> OK,  it's may not be an excellent solution but the effect would be
> great. For example:
>
> { "US", "BR", "CA", "RU", "FR" }  => { US, BR, CA, RU, FR }
>
> Using 1 and 3 together:
>
> countries = { "US", "BR", "CA", "RU", "FR" }  => { US  BR  CA  RU  FR }
> colors = { "red", "green", "blue", "yellow", "black" }  => { red green
> blue yellow black }
>
> Well, That´s it.
>
> --
> Nilson

First, I really like (2). I've made the mistake of trying to use the
"function name() ..." syntax inside tables before.

I like (1) if it doesn't break anything. The first thing that popped
into my head is that it would eliminate the possibility of adding
C-style string literal concatenation to Lua in the future.

To be more specific, the C compiler concatenates literal strings
separated by whitespace, e.g.

    const char s[] = "Hi "    "there.";    //s[] will contain "Hi
there."
   
This is incompatible with the proposal. t = { "a" "b" } would become
ambiguous, it could mean either of the following:

    t = { [1]="a", [2]="b" }

or

    t = { "ab" }

I don't know if automatic string literal concatenation is a feature that
has been proposed -- I couldn't find anything about it in the archives.
It isn't a feature I feel strongly about, but I think we should be aware
we'd be locking out that possibility.


John Giors
Independent Programmer
Three Eyes Software
[hidden email]
http://www.ThreeEyesSoftware.com




Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Geoff Leyland
In reply to this post by Jonathan Castello-2
On 21/09/2010, at 7:58 PM, Jonathan Castello wrote:

> On Tue, Sep 21, 2010 at 12:48 AM, Benoit Germain <[hidden email]> wrote:
>> <snip> ... maybe others have a different opinion on the subject?
>
> Personally, I favor Ruby's approach, which I believe uses newlines as
> an effective syntactic hint to determine what your intent probably
> was. It has optional semicolons, which you generally need to use if
> you want to squish two statements onto one line (since as mentioned,
> newlines are used as hints).
>
> In most languages I've seen, it's uncommon to put multiple stand-alone
> statements on the same line. Why use a semicolon where a newline would
> do?

Perhaps because it's not uncommon to put a single statement on several lines?  For this very contrived example:

call_a_function_with_a_long_name(and_a_long_argument)
  ("and_call_the_result"):sub(and_so_on)

Lua 5.1 would complain and I understand Lua 5.2 would interpret it as one statement.  What would Ruby do?

In both 5.1 and 5.2 if I want it to be two statements, then I can use a semicolon, but I if I understand what you propose, I can't break my long line at that point (I know, I could break it other places) and have it be interpreted as a single statement - unless we have a continuation character like FORTRAN and VB.

(I'm not arguing for or against any of your, Benoit or Juris's ideas, I'm just being a nitpicker.  I am against a continuation character though!).

Cheers,
Geoff


Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

steve donovan
On Tue, Sep 21, 2010 at 10:34 AM, Geoff Leyland
<[hidden email]> wrote:
> (I'm not arguing for or against any of your, Benoit or Juris's ideas, I'm just being a nitpicker.  I am against a continuation character though!).

That's good!  We would all rise up howling - if it was an actual
feature, how could Roberto hold his head up when the language
designers all get together for beer?

-1 for mandatory semi-colons, BTW

steve d.

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Geoff Leyland
On 21/09/2010, at 8:38 PM, steve donovan wrote:

> On Tue, Sep 21, 2010 at 10:34 AM, Geoff Leyland
> <[hidden email]> wrote:
>> (I'm not arguing for or against any of your, Benoit or Juris's ideas, I'm just being a nitpicker.  I am against a continuation character though!).
>
> That's good!  We would all rise up howling - if it was an actual
> feature, how could Roberto hold his head up when the language
> designers all get together for beer?

I *do* think comments should be started with a "c" in the first column though :-)


Reply | Threaded
Open this post in threaded view
|

RE: Some enhancements in table initializations

Benoit Germain
In reply to this post by steve donovan


> -----Message d'origine-----
> De : [hidden email] [mailto:[hidden email]]
> De la part de steve donovan
> Envoyé : mardi 21 septembre 2010 10:39
> À : Lua mailing list
> Objet : Re: Some enhancements in table initializations
>
> -1 for mandatory semi-colons, BTW

Well, I certainly don't propose this, I simply ask what the actual benefit is of not having them? As I said, I don't use them, but I could just as easily do. I don't especially miss a mandatory statement separator, as long as I don't have to second-guess what the parser will decide what bytecode to generate, or what is valid syntax or not depending on the way I break lines :-).

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
In reply to this post by Geoff Leyland
On Tue, Sep 21, 2010 at 1:34 AM, Geoff Leyland
<[hidden email]> wrote:
> Perhaps because it's not uncommon to put a single statement on several lines?  For this very contrived example:
>
> call_a_function_with_a_long_name(and_a_long_argument)
>  ("and_call_the_result"):sub(and_so_on)
>
> Lua 5.1 would complain and I understand Lua 5.2 would interpret it as one statement.  What would Ruby do?
>
> In both 5.1 and 5.2 if I want it to be two statements, then I can use a semicolon, but I if I understand what you propose, I can't break my long line at that point (I know, I could break it other places) and have it be interpreted as a single statement - unless we have a continuation character like FORTRAN and VB.

I admit, that's a good point. I think Ruby manages it by virtue of not
really using () as an invocation operator. In Ruby, "foo.bar" is how a
method is called, and () is incidental to that purpose. "Callable"
objects are just objects that define #call and #[] methods. So your
example is more like this in Ruby

call_a_function_with_a_long_name(and_a_long_argument)
  .call("and_call_the_result")
  .sub(and_so_on)

Despite the first line being a full statement in its own right, Ruby
does treat the whole thing as a single statement (Just don't try this
in a REPL without a begin/end block around it, like I almost did...) I
had quite a bit of fun playing with a Lua implementation of a
Ruby-like object model, so I'm relatively familiar with how Ruby and
Lua differ in terms of methods. :)

As far as Lua goes, I prefer the greedy approach Lua 5.2 introduces
for the one case in 5.1 where a newline matters. Unfortunately, my
environmental-indexing suggestion goes completely against this
approach, since something like this would look sane to the developer,
yet Lua would understand it differently:

foo()
[42] = bar()

~Jonathan

Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

Jonathan Castello-2
On Tue, Sep 21, 2010 at 2:44 AM, Jonathan Castello <[hidden email]> wrote:
> As far as Lua goes, I prefer the greedy approach Lua 5.2 introduces
> for the one case in 5.1 where a newline matters. Unfortunately, my
> environmental-indexing suggestion goes completely against this
> approach, since something like this would look sane to the developer,
> yet Lua would understand it differently:

It's late and I forgot to mention this: In your example, the second
interpretation - one statement followed by another - is also logical
and I would prefer it in many instances too. It's just the fine lines
a language must walk, I suppose...

~Jonathan

pj
Reply | Threaded
Open this post in threaded view
|

Re: Some enhancements in table initializations

pj
In reply to this post by Nilson
Geoff Leyland wrote:
> In most languages I've seen, it's uncommon to put multiple
> stand-alone statements on the same line.

Well, I do it quite a lot; e.g.
   i=1; j=1; k=1;
where the three statements form a semantic unit. Just like in
maths prose you might see: "In the x=1 y=3 case this becomes..."

Or:
   param1 = string.byte(trackdata, i); i = i+1
   param2 = string.byte(trackdata, i); i = i+1
where it's vital that the extraction of the parameter never gets
separated from the increment of the index.

> Why use a semicolon where a newline would do?

It saves space on the screen, thus giving a better overview of
the code while editing.

I must say, though, that I'd suffer mandatory newlines any day
rather than the the kind of de-whitespaced javascript you often
see, with all semicolons and no newlines (shudder...)

Regards,  Peter Billam

http://www.pjb.com.au       [hidden email]      (03) 6278 9410
"Was der Meister nicht kann,   vermöcht es der Knabe, hätt er
 ihm immer gehorcht?"   Siegfried to Mime, from Act 1 Scene 2


12