Re: hpairs?

[David Manura <dm.lua@...>]

On Wed, Dec 29, 2010 at 11:26 AM, Richard Hundt <richardhundt@gmail.com> wrote:
> which is a sort of table based op tree inspired by metalua syntax, which
> gets converted to bytecode by the code generator.[...]
>On 12/29/2010 04:28 PM, Luiz Henrique de Figueiredo wrote:
>> Also, can't you emit Lua source code instead of bytecode? As you
>> probably know, bytecode is not portable across versions of Lua;
>> e.g., 5.1 bytecode does not run in 5.2 and vice-versa.
> There are two reasons for going to bytecode. The first is that Lua the
> language doesn't let you do arbitrary branching, so a language with a
> 'continue label' construct is hard to transform to Lua source. The other
> reason is that when producing bytecode you've got control over the debug
> data (line numbering, variable names etc.) which you see in stack traces.

The same problems with emitting source code rather than bytecode have
been observed in the context of Metalua, SourceOptimizer, and other
preprocessors [1-4], particularly with respect to debug information
and supporting statements in expressions (at least without resorting
to anonymous closures [*]).  Difficulties in expressing arbitrary
branching (continue or goto) in Lua were also discussed in the context
of Clue [5-7], which is a C -> Lua translator, and LuaJIT2, whose
bytecode doesn't support arbitrary branching either.  It's not
impossible to transform statements-in-expressions and arbitrary
branching in terms of Lua code, though it can look ugly as seen in
SourceOptimizer and Clue.  There are also some ways to trick the Lua
compiler into injecting debug info into the bytecode [2], though these
are not entirely general.  However, maybe rather than injecting your
own debug info into the bytecode, you could alter the error handler
(debug.traceback) to display more meaningful errors in terms of the
original source--isn't that basically the approach taken by crash
reporter tools for C/C++ that target machine code?

[1] http://lua-users.org/lists/lua-l/2007-04/msg00320.html
[2] http://lua-users.org/lists/lua-l/2010-06/msg00311.html (bottom)
[3] http://lua-users.org/lists/lua-l/2009-11/msg00183.html
[4] http://lua-users.org/lists/lua-l/2009-05/msg00288.html (bottom)
[5] http://lua-users.org/lists/lua-l/2008-07/msg00574.html
[6] http://lua-users.org/lists/lua-l/2009-11/msg00049.html
[7] http://lua-users.org/lists/lua-l/2008-07/msg00274.html
[*] which can have an performance impact, though slightly mitigated in
5.2-alpha with closure caching and elimination of environments and
also mitigated somewhat in LuaJIT, though not really as LuaJIT uses
5.1 semantics --
http://lua-users.org/lists/lua-l/2010-11/msg00815.html .  Also, the
anonymous closure increases the stack level, which may affect
debugging (debug.traceback) and getfenv/setfenv behavior.