[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: RFE: table ctor syntax enhancement for many-to-one mappings
- From: Lorenzo Donati <lorenzodonatibz@...>
- Date: Fri, 19 Aug 2011 17:29:53 +0200
On 19/08/2011 15.33, Dirk Laurie wrote:
[...]
A less trivial example of the proposed syntax extension would be:
tbl = { ['a','b','c']=good, [4,5,6]=bad, [7,'8','9']=so_so }
with `good`, `bad` and `so_so` already defined. This suggests strongly
that tbl.a, tbl.b and tbl.c are to be initialized with the same value.
But in a later post, there is the suggestion that this could be
implemented as syntactic sugar for
tbl={}
tbl['a']=good; tbl['b']=good; tbl['c']=good;
tbl[4]=bad; tbl[5]=bad; tbl[6]=bad;
tbl[7]=so_so; tbl['8']=so_so; tbl['9']=so_so;
Aha! I see your objection! Very good point! Thank you for catching this!
Clearly I haven't thought so well about the case where the "val" on RHS
is not immutable.
Now, I take the following special case.
tbl = { ['a','b','c']={}, [4,5,6]={}, [7,'8','9']={} }
Yes, this case could be ambiguous to the reader. Now I see that the
simple "syntactic sugar" approach in this case falls short, i.e. it
would provide the wrong semantics, i.e. it would create a new empty
table for each LHS expression, which is not what I was thinking of.
This does not mean:
tbl={}
tbl['a']={}; tbl['b']={}; tbl['c']={};
tbl[4]={}; tbl[5]={}; tbl[6]={};
tbl[7]={}; tbl['8']={}; tbl['9']={};
But shouldn't it sometimes mean that? If tbl.a, tbl.b and tbl.c are
initialized with the same table value, do we want them to refer
permanently to the actual same table? In which case, why are there
three items, not just one? Or should they refer to different tables,
that happen to have equal contents at the start? Deep waters, ambiguity.
Yes, you have really found a weak point of my proposal. I still feel
that the "right" semantics would mean that tbl.a, tbl.b and tbl.c all
point to the same object (since that will be the semantics of a
many-to-one mapping), but this surely cannot be done with the code
transformation I proposed. This has to be taken care of deeper in the
parser then.
I don't think that the alternative, i.e. making several "copies" of an
empty table (to stick to your example) would be good semantically. I
admit that someone could think that way (so the readability in this case
would suffer), but we could add to the proposal that the single value
RHS must be fully evaluated before assigning them. As I said, this is no
more a matter of a simple code transformation.
Maybe with this:
t = { 1, 2, x = 2, ['a', 'b', 'c'] = {}, ['d', 'e'] = { 42 }, 'hello' }
could be transformed into:
t = { 1, 2, x = 2 }
local tmp1 = {} -- hidden var
t.a = tmp1; t.b = tmp1; t.c = tmp1
local tmp2 = { 42 } -- hidden var
t.d = tmp2; t.e = tmp2
t[#t+1] = 'hello'
But it seems a bit too ugly, i.e. a transformation that is easy (but
verbose) for a human, but awkward to build in the parser (I'm trying to
think of more complex cases here).
So it seems the "syntactic sugar" way seems impractical.
Now suppose, just suppose, that Lua allowed the Python-like syntax:
a=b=c=1; d=e=f=2 --etc
Then it would be quite reasonable to ask that
tbl = { a=b=c=good, [4]=[5]=[6]=bad, [7]=['8']=['9']=so_so }
also be legal.
Should one not rather be lobbying for that extension?
No. As for myself, I wouldn't like to go down that hill.
My motivation wasn't merely to shorten Lua syntax (otherwise I would
have lobbied for {...} instead of do ... end ;-)
I appreciate the carefully balanced "verbosity" of Lua. The point I was
trying to make is that it is difficult to express *clearly upfront* a
very basic, useful, general and common concept (many-to-one) mappings
with current syntax.
I don't miss some of the shortcuts of C/C++/Java, such as x+=2 or
a=b=c=d=1 or similar things.
I think syntax should not be designed with the focus of simplifying
writing code. The design goal should be simplifying *reading* code.
You pointed out a flaw in the "code transformation" suggestion (which
regarded the implementation), but the proposal in itself seems still
valid to me, from a syntax/semantics POV (unless someone finds another
big flaw ;-)
Dirk
(who more than once wrote `a=10*[MyObject()]` in Python and debugged
for hours, in the days before deciding to switch to Lua)
Thanks for the feedback.
--Lorenzo