lua-users home
lua-l archive

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

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['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['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 ;-)


(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.