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

[HyperHacker <hyperhacker@...>]

On Mon, Aug 22, 2011 at 02:58, Jerome Vuarand <jerome.vuarand@gmail.com> wrote:
> 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.
>
>

I've often wished t[x,y,z] were legal when t has a __index or
__newindex, and would pass x,y,z as arguments to them. It'd be very
handy for things like image manipulation and matrices.

-- 
Sent from my toaster.