Re: ... as an lvalue

["Alex Davies" <alex.mania@...>]

Mike Pall wrote:
> Umm, no. Another stack drives up complexity. We already have two
> semi-synchronous stacks (TValue stack and Callinfo aka the frame
> stack). I've gotten rid of Callinfo completely in LuaJIT 2.x -- it
> improved performance remarkably and simplified many code paths.

Hmm, not sure I agree that a second, rarely used, stack would complicate 
anything more then the current varargs-between-frames. Working on the old 
principle of optimizing the most common case, it allows simplifying CI usage 
in at least one way I can think of. Remove ci->func, and the running 
function is always at L->base-1. (I imagine jit 2.x simplifies the whole 
structure down to 8-16 bytes in ways I cannot see however.) Keep the vararg 
top/bottom references as numbers in the stack so CI doesn't get bloated to 
aid rarely used vararg functions. I am open to that it would bloat lua_State 
a little more though, and possibly introduce more rare bugs that only apply 
to vararg functions..

Mike Pall wrote:
> Introducing another stack/queue is certainly not the way to go.
> First you have to put in all the magic to make the compiler
> recognize the append/prepend cases to keep them O(1). And then you
> have to implement a data structure that can efficiently grow on
> either side and still avoid pathological unbounded growth. And you
> somehow need to attach it to the current frame and keep many of
> these data structures at once for all vararg frames. Ugh ...

Append/prepend are easy enough to detect - they only occur when the last 
instruction was a vararg, just combine that with the set vararg op. The 
second stack/queue need only grow in one direction. The values would have to 
be stored "upside down", such that:

varargfunc(1, 2, 3)

base -> 3, 2, 1

Removing the front merely increments base, Adding an element to the front of 
the list simply adds to top. Exiting a vararg function just restores the 
previous base and top. It is true that there would be unbound growth if used 
in a very unusual fashion, but not really a problem imo.

> This probably looks like line-noise for anyone not as deep into
> Lua as you and me. It's very unlikely that '...' as an lvalue is a
> concept that can be easily comprehended and safely used. Without
> an efficient append-at-front this would be O(n^2) again. I'm not
> sure you want to write the docs explaining all the cases that do
> lead to degenerate behaviour and those that don't.

Despite arguing that it wouldn't be that complicated (I really don't believe 
it would), I agree here. Although it's original intended uses still seem 
clearer to me then the alternative of creating skip2 function wrappers, I 
thought I'd entertain a few ways to abuse it which allow things Lua 
currently doesn't :). I only really bumped the post because of how 
efficiently it allows writing unpack. I particularly like any feature that 
requires some current functions to be written in C to be effective.

It probably worked more as a counter-argument then a for-argument however.

> apairs() would be a simple 10-line addition to the standard
> library and requires no changes to the Lua core.

That's true, I've got an apairs as part of my own base library. Useful for 
the rare varargs function you write..

Sorry for the noise :)

- Alex