Re: Multi-indexed tables

[Philippe Verdy <verdy_p@...>]

As well the code t[a+2] would definitely generate several opcodes to compute a+2 before using it as key in GETTABLE R(A), R(t), R(a+2), where R(t) is the register holder the table t, and R(a+2) is the register containing the computed value of key (a+2)...

The only limit is syntaxic and the semantic we want to apply to that syntax "t[1, 2]". The opcodes in the LuaVM is definitely not an issue.

Le dim. 9 déc. 2018 à 23:15, Philippe Verdy <verdy_p@wanadoo.fr> a écrit :

op codes are not an issue at all here; there's still a sequence of opcodes possible to compute RK(C) in a register mapping the expected key from the pair.

Even the code "t[1][2]" would also generate a sequence (GETTABLE;SETTABLE) or (GETTABLE,GETTABLE) and not a single opcode...

Le dim. 9 déc. 2018 à 20:47, Dibyendu Majumdar <mobile@majumdar.org.uk> a écrit :

Hi,

On Sun, 9 Dec 2018 at 18:12, Dirk Laurie <dirk.laurie@gmail.com> wrote:
>
> 1. Is there any syntactic reason why one can't patch Lua so that
> t[1,2] won't raise a compilation error, but instead invoke
> __index(t,1,2) or __newindex(t,1,2,v)?

I think there are issues with the way the table op codes work - and
the number of registers they allow.

GETTABLE A B C   R(A) := R(B)[RK(C)]
SETTABLE A B C   R(A)[RK(B)] := RK(C)

The opcode doesn't have room for additional registers.

Lua's parsing also assumes that there is a single register for the key.

Regards
Dibyendu