Re: L2: Lua compiler in the works

["Humberto S. N. dos Anjos" <h.anjos@...>]

Actually, no dynamic language (think Lua, Python, Ruby and the like) is friendly to static optimizations, because almost everything is left to runtime. This allows for some extremely cool stuff, but the code generator has to assume worst-case scenarios for pretty much everything.

But on most programs, very little truly dynamic code (things such as debug.setmetatable, loadstring with a string built at runtime, explicit setfenv stuff) is actually used, although any uses made are vital to the program's semantics (this is a paraphrase from a paper offering a type inferencer for Python, but the same reasoning applies here). So the main purpose of this compiler is to see how many static optimizations can be reasonably used. 

Of course, some assumptions have to be made to make static optimizing viable. I came up with some, although now they seem a bit too strong:

- the debug library isn't used. The Lua manual recommends against it, because it can violate some Lua assumptions (local variables can't be accessed outside of their scope, numbers and functions can't have metatables), and it can be slow. So I assume no hackery of this sort is going on.

- basic modules and functions won't be modified, or at least not in a way that alters their semantics. With this I can rely on documented behavior to precompile functions calls, like compiling string.rep("a", 3) directly to "aaa". This might appear with some frequency when function calls are inlined.

On Nov 19, 2007 2:33 PM, Mark Hamburg <mhamburg@adobe.com> wrote:

Given metamethods, how much can actually be optimized? Do you have examples
of the sorts of code your optimizer can improve? The prospect of code
optimization is certainly attractive, but my understanding had been that Lua
wasn't particularly friendly to such optimizations.

Mark

-- 
_______________________
Humberto S. N. dos Anjos

<insert witty quote here>