Re: RFE: table ctor syntax enhancement for many-to-one mappings

[Jerome Vuarand <jerome.vuarand@...>]

2011/8/19 Lorenzo Donati <lorenzodonatibz@interfree.it>:
> 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 :-)

You can add to the cons list the fact that your proposal would
conflict with another one, that is the use of several values (tuples?)
as keys into tables. For example you could imagine that in the future
the following becomes legal :

local img1,w,h = load("foo.png")
local img2 = {}
for y=1,img1.height do
  for x=1,img1.width do
    img2[y, x] = transpixel(img1[y, x])
  end
end

Of course this is not yet part of Lua, and may never be, so don't
worry too much about it. But if I were to choose between your
syntactic sugar, and a potentially very useful new semantic, I'd pick
the latter.