RE: Table constructors

["Ashley Fryer" <lua@...>]

> Behalf Of Roberto Ierusalimschy
>
> There is a single "settable" opcode (the SETLIST), that stores the 3
> elements on the stack in successive positions of the array, starting at
> index 1. When there are too many elements in a list constructor, then we
> generate intermediate SETLIST opcodes, in blocks of 64 elements (to avoid
> too much grow of the stack). Currently, the SETLIST cannot start counting
> at arbitrary indices, only at "multiples" of 64 (this is the
> argument 0 in
> the SETLIST opcode. The first index should be 0*64+1, last index
> should be
> 0*64+3). A similar approach is used for record-style fields, with SETMAP.
>
> The new syntax would have two drawbacks: First, if we keep the current
> opcodes, the only easy implementation would be to start each new series of
> list-like elements in 1 again:
>
>   { 10, 12, a=b, 13, 14} --> {[1]=10, [2]=12, a=b, [1]=13, [2]=14}
>
> The 10, 12 at the beginning of the constructor are simply thrown
> away. This
> seems to be too literal an interpretation of "there's no wrong answer".

LOL!  Well, I walked into that one.

So the main implementation issue is that SETLIST and SETMAP don't accept
arbitrary ranges on the stack.

If they did, then you could do this:

{ 10, 12, a=b, 13, 14 }

produces:

CREATEARRAY   4     -- 4 numbers total
PUSHNUMBER    10
PUSHNUMBER    12
CREATEMAP     1
PUSHOBJECT    a     -- however this works
PUSHOBJECT    b     --    "    "
SETMAP        2  4  -- pops the map elements
PUSHNUMBER    13
PUSHNUMBER    14
SETLIST       0  4


>
> Second, even if we create a new opcode that starts storing list
> elements at
> arbitrary positions, the efficiency would suffer; for instance,
>
>   {1,2,3,4; a=1, b=2, c=3, y=4}
>
> needs only one SETLIST and one SETMAP, but
>
>   {1, a=1, 2, b=2, 3, c=3, 4, y=4}
>
> would need four SETLISTs and four SETMAPs. So, the new form would be
> uglier (to our eyes) and slower.
>

If the approach I mentioned were used, it would result in four SETMAPs and
one SETLIST, which is better but not good.  Regardless, the example above is
a pathological case and I think it would be rare.  Most of the time, the
results of the new syntax would be the same as the old syntax.  The only
difference would be that people wouldn't have to type a semicolon in the
middle of the list.

Anyway, the proposed syntax would be a Good Thing from the user-side because
table usage would become more flexible and consistent.  Implementation
difficulties are something we can all appreciate, but at least engineering
issues are something we can hope to resolve.  :-)

Thanks Roberto!

ashley