[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Some enhancements in table initializations
- From: Nilson <nilson.brazil@...>
- Date: Tue, 21 Sep 2010 00:29:40 -0300
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