lua-users home
lua-l archive

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


In my view, tuples are a *big* change to the language, no matter the
size of its implementation (which is "an implementation detail", after
all).

That change would add lots of complexity to the language, at least
"hidden" complexity. As soon as we decided to add tuples to Lua, lots of
other decisions would follow, with lots of discussions for each of those
decisions. Among others (without much thinking): are tuples immutable?
if so, how should be the semantics of tupple equality? do tuples have
metatables? Why not? should we have a "foreach" function for tuples? A
"pair" iterator? Weak tuples? Each of these subjects (and many many
others) would eventually emerge in the list; several times, probably.

If the argument about efficiency is valid (the one about three
allocations versus one), I don't see why we cannot simply implement
tables more efficiently for those particular uses. First, as long as we
do not use a ".n" field, we are down to two allocations. (Would that
simple change give a 1/3 speedup?) Second, we could allocate tables with
a variable tail where it would keep its original array part (the one
specified in its constructor, if smaller than some [small] limit). That
would be enough to use only one block for those tables.  (The main point
here is: how frequently we add new integer indices to tables created
with list constructors?)

About the "... hack", I do not see it as a hack at all (but of course
this is a matter of taste). It is a local change to the language, and it
solves at least two problems: it allows an easy way to pass parameters
to main chunks and it eliminates the magic name "arg" (or is it "args"?
I can't remember ;).

-- Roberto