Re: Lua 5.1+ and variable-argument tables

[Edgar Toernig <froese@...>]

Rici Lake wrote:
> 
> On 19-Aug-04, at 6:21 PM, Edgar Toernig wrote:
> 
> > Maybe.  But the whole point of the change is to avoid allocating
> > a (usually short-living) heap object on each vararg-function
> > invocation.
> 
> I understand that.

IMHO that's the most important point.  If you accept heap allocation
during vararg-function invocation you can stick with tables.  The
slight performance advantage of your tuple implementation could
be nullified by optimizing the appropriate parts of table creation.

> Personally I'd be more interested in an
> optimisation which avoids allocating short-lived heap objects
> for curried functions, for example.

The currying is supposed to create a new object, isn't it?

The invocation of the curried function is another thing.
The implementation I posted some minutes ago does not allocate
any heap object when calling the curried function...

> The tuple proposal is an attempt to reduce the number of short-lived
> heap objects created for vararg-function invocations from three to one.

Hmmm... nitpicking: from the GC point of view a table is one
object (with one to three malloced areas).

> > Your tuple proposal just introduces a new datatype.  All the
> > syntax extensions could equally well be implemented for tables.
> > Where's the tuple variant better than a regular table?  Any
> > performance differences would only be implementation details.
> 
> Well, the same could be said for the ... hack; the performance
> difference is only an implementation detail.

No.  It's a conceptual difference.  The ... "hack" is designed
to not allocate heap objects, the tuple solution is designed
to allocate a new object.

> Now, it's true that the tuple proposal is (more or less) a new datatype,
> although it is actually implemented on top of an existing datatype
> (that is, a C-function). The implementation, shorn of the new syntax,
> is less than 10 lines of code.

Afaics, only the syntax gives anything new.  The tuples themself
give nothing new.  They are only a subset of tables.

> For example, they [tuples] provide a handy way to collect multiple
> return values, an issue I believe you yourself noted in an earlier
> posting on the subject of ...

I did.  But it's not the tuple that makes it possible to collect
multiple return value but the new syntax.

> I combine that with another question: is the ... thing worth a fairly 
> considerable complication to the Lua core when functional tuples 
> provide a reasonably optimised solution to the varargs issue, along 
> with other issues?

As I said, tuples require heap objects, the dots do not.

And I wouldn't call it a "considerable complication to the Lua core".
I can't speak about Lua5 but I added them to Sol (Lua4 based) and
it's not that hard (I simply move the varargs to the up-to-now
unused upper end of the stack).

Ciao, ET.