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

[HyperHacker <hyperhacker@...>]

On Thu, Aug 18, 2011 at 14:46, Lorenzo Donati
<lorenzodonatibz@interfree.it> wrote:
> Hi all!
>
> I stumbled into this idea while writing a long set-like table. Wouldn't it
> be nice if the follwing:
>
>
> set = { a = true, b = true, [1] = true }
>
> could be abbreviated as:
>
> set = { ["a","b",1] = true }
>
> ?
>
> In other words I propose to enhance the table constructor syntax to allow
> not just one expression inside "[]", but an expression list, so that:
>
> [exp1,exp2,exp3,...] = val
>
> would be expanded as
>
> [exp1] = val, [exp2] = val, [exp3] = val, ...
>
> this would greatly simplify writing many-to-one mappings and would also be
> more symmetric with current typical one-to-many mappings:
>
> exp = {val1, val2, val3, ... }
>
>
> It seems an easy change and it shouldn't confuse the parser or complicate it
> too much (there aren't contexts where an expression list can appear inside
> square brackets, if I'm not mistaken).
>
> This could also interact nicely with multiple returns and varargs:
>
>
> { [func()] = true }
>
> will make a set out of all the return values of f; and this would be the set
> of all the values passed to a vararg func:
>
> { [...] = true }
>
> Expanding on this, we could write even more complex mappings in an easy way,
> without writing maps the other way around and then reversing them:
>
> errors = {
>  [ "bad arg", "out of range", "invalid type" ] = "resumable",
>  [ "core dump", "out of memory", "disk full" ] = "fatal",
> }
>
> instead of
>
> errors = { -- silly long way
>  ["bad arg"] = "resumable",
>  ["out of range"] = "resumable",
>  ["invalid type" ] = "resumable",
>  ["core dump" ] = "fatal",
>  ["out of memory" ] = "fatal",
>  ["disk full" ] = "fatal",
> }
>
> or (smarter way - having a suitable reverse_map function)
>
> errors = reverse_map {
>  resumable = { "bad arg", "out of range", "invalid type" },
>  fatal = { "core dump", "out of memory", "disk full" },
> }
>
>
> I wonder why such a clear and readable syntax alternative isn't already in
> Lua. Since I'm definitely not a language designer I suspect that there are
> some pitfalls I haven't considered, or maybe it could bloat Lua too much
> from an implementation POV.
>
> Anyway even if it is a more stupid proposal than it seems to me, I hope to
> get new insights from whoever will be so kind to share an opinion.
>
> Any feedback appreciated.
> TIA
>
> -- Lorenzo
>
>
>
>
>
>
>
>
>

This seems not too far from the typical multiple assignments:
a, b, c = 1, 2, 3
I often wondered why that can't be done in tables. I'm guessing the
answer is ambiguity: does a, b, c = 1, 2 mean [1]=a, ['b']=1, ['c']=2
or ['a']=1, ['b']=2, [1]=c or ['a']=1, ['b']=2, ['c']=nil? This might
be resolvable with some kind of syntax extension such as (a,b,c) =
(1,2,3) and just requiring equal number of values on left/right sides,
since you can't store nil in a table anyway (so a,b,c = 1,2 doesn't
really make sense).

What I usually do in a case like yours is to define short local aliases:
local r, f = "resumable", "fatal"
local e = {}
--resumable
e["bad arg"], e["out of range"], e["invalid type" ] = r, r, r
--fatal
e["core dump" ], e["out of memory" ], e["disk full" ] = f, f, f
errors = e

Something similar to your idea could be done with a 'rep' function: a,
b, c = rep(3, true) --returns true, true, true. That would let you do
similar to my snippet above without needing the local aliases, which
might look a little nicer.

-- 
Sent from my toaster.