 |
lua-l archive |
|
|
||
|
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