Re: Some enhancements in table initializations

[<jgiors@...>]

> -------- Original Message --------
> Date: Tue, 21 Sep 2010 00:29:40 -0300
> From: Nilson <nilson.brazil@gmail.com>
> Subject: Some enhancements in table initializations
> To: lua-l@lists.lua.org
> Message-ID:
> 	<AANLkTikAbFVKYs+hgsKKvFNTo2WHNNnA22=bEdMkn6aG@mail.gmail.com>
> 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
jgiors@ThreeEyesSoftware.com
http://www.ThreeEyesSoftware.com