Re: Some enhancements in table initializations

[Jonathan Castello <twisolar@...>]

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 <nilson.brazil@gmail.com> 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
>
>