Re: [ANN] Lua Alchemy v0.3.1

[Axel Kittenberger <axkibe@...>]

> Might be worthy to remind of the pretty interesting
> https://github.com/mherkender/lua.js project in this thread (expanding
> on the "etc." quoted above ;) )

Its a nice start, but needs IMHO a lot of work on proper execution
When I try this
____________
local a = {};
local b = {};
b[a] = 'hallo';
print(b[a]);
print(b.a);
____________
I get
____________
Error: Unsupported key for table: object
____________

One can argue if support for __mode and __gc can be dropped for a
javascript implementation, but no associative arrays isn't close to be
proper Lua. It wouldn't be too difficult to add an ID to every project
generated and use that as string-based index.

Secondly I disagree that even support of __mode and __gc would be
"much slower". The author is thinking here of a doing a vanilla VM in
javascript, which is of course the horrors regarding speed, but one
can also do a "JIT". Something that generates javascript on the fly,
just as LuaJIT generates assembler on the fly. Yes, one can argue if
it still insane to use a GC within a GC-Language, but you can generate
Javascript, keep one big tabe of all objects ever generated, and once
in a while to a mark&sweep walk like a native GC, and just remove
references of objects considered to be sweeped, and set weak
references to 'undefined'. Its a little double with the native GC
having to the same another time, but it isn't that bad.

I understand that having every function return an array is a solution
to implement multiple return values in JS. On the other hand, I guess
adding "registers" as global variables to return from functions would
improve performance.

Finally, as long the Closure Compiler can significiantly improve your
generated code, you can improve code generation :-)