lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index] 

On 19/08/2011 11.21, Patrick Rapin wrote:

I stumbled into this idea while writing a long set-like table. Wouldn't it
be nice if the following:
   set = { a = true, b = true, [1] = true }
could be abbreviated as:
   set = { ["a","b",1] = true }


I second this idea, it would be a useful addition.
Several times, I would have used such a feature if it was available.
Instead, my preferred method is to use something similar to the
reverse_map() example.
That syntax should be added to Lua if (and only if) it was easy to implement.
Unfortunately, I doubt that the implementation is so easy: it looks
like the parser would have to look ahead an arbitrary number of tokens
before knowing what to do with the first field.
I'm not an expert, but isn't the parser already capable of processing arbitrarily long expression lists when it comes to function definitions and function calls? The only difference would be the delimiters, which in the former case are "()" and in my proposal would be "[]".
BTW, it seems to me (I may be wrong, so any correction is appreciated) that it is a simple matter of code transformation, which could (theoretically) be done in a (hypothetical) preprocessing step: 

anytime in a table ctor you see a fragment like:

[exp1, exp2, exp3, ..., expN] = val

expand it as:

[exp1] = val, [exp2] = val, [exp3] = val, ..., [expN] = val

therefore it may also be implemented as "syntactic sugar".


Maybe it is worth summarizing the pros/cons of the proposal:

Pros:
1.Very elegant: fits neatly Lua syntax, it adds symmetry to table ctors ("many keys-> one value" as well as the alreay feasible "one key -> many values").
2. Very readable: it will make the intention of the coder extremely clear (especially for sets, which currently are always a bit "hidden" among code: simply write { [elem1, elem2, elem3, ... ] = true })
3. backward compatible: doesn't break existing syntax, dosen't introduce new symbols/tokens.
4. if not implemented as code transformation, it may be amenable to optimizations (once you have all the keys between "[]" you could preallocate space in one shot)
5. Quite general (in its domain - table ctors), it is not a "single use case solution".
6. Solves a problem that otherwise leads to very verbose solutions, which hide a very clear, generally useful and widespread concept (many-to-one mappings) 



Cons:
(just guessing - since I'm not a language designer, nor do I know Lua internals very well)
1. May confuse the parser, so it is infeasible with current parser structure.
2. Even if reasonably feasible, it could bloat Lua, because the mods will add substantial weight, and so wouldn't match the "lightweight criteria" of Lua team.
3. Even if it could be implemented easily and without adding much weight, it will degrade compiler performance unacceptably.
4. Even if performance is not degraded much, it will affect compilation time even when the feature is not used (because of added parser complexity).
5. It may increase the memory requirements of the compiler unacceptably (problematic on embedded systems?) 

6. Is not implementable in a one-pass compiler (?)

7. It may complicate Lua grammar unacceptably.
8. The syntax may conflict with existing usage (array indexing? - but contexts seem fairly separate - I don't know). 

... add your own :-)