lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]

Oops, just noticed it's JavaScript->Lua, not the reverse (if the
intention is runninng JavaScript on J2ME maybe is
more useful, though).

Compiling JavaScript function scope to Lua lexical scope is easy, too,
if your variable names are already unique (i.e. you know which
specific declaration covers each use). The semantic mismatch in all
operations cut both ways, too, but you can probably get away with
using Lua tables for JavaScript objects and have JavaScripts
compile to Lua's (metatables go a long way here).

JavaScript will run even slower in Kahlua than Lua code does, though,
but maybe your application won't care... sorry for immediately
assuming Lua->JavaScript, but you usually compile nicer languages to
uglier ones, so you can program in the nicer ones. :-)

Fabio Mascarenhas

On Thu, Oct 2, 2008 at 1:33 PM, Fabio Mascarenhas <> wrote:
> On Thu, Oct 2, 2008 at 9:02 AM, David Given <> wrote:
>> steve donovan wrote:
>> [...]
>> But life is made more complex by the way that Javascript variables don't
>> really work the same way that Lua ones do --- *all* 'var' variables end
>> up in the equivalent of the local environment, I believe, and I'm not
>> entirely sure of when new environments show up.
> Mapping Lua's lexical scope into JavaScript's function scope is easy,
> rename the variables so the scopes don't clash, and fix the
> references. It's even easier if you are compiling to a newer
> JavaScript implementation and use let instead of var.
> Implementing all the rest of Lua's semantics is the hard part,
> JavaScript's semantics are just superficially similar to Lua's, they
> are in fact quite different. Basically every Lua operation will have
> to be compiled to JavaScript code that checks the types of the values
> involved and implement the correct semantics. Even a simple operation
> as a+b would be compiled to the "add_event" code on section 2.8 of
> Lua's reference manual, translated to JavaScript, of course. Likewise
> for indexing, and even function calls (as functions are not the only
> callable object in Lua).
> It's pretty straightforward, though, and Mozilla's tracing JIT could
> probably eliminate a lot of the overhead in the hot paths (if all the
> extra code doesn't push the hot paths above their maximum size).
> SquirrelFish and V8 wouldn't fare as well. In the end, JavaScript is
> just as alien to Lua's semantics as the JVM or CLR.
>> (I'd like to find out about this stuff at some point, but the Javascript
>> reference documentation is largely incomprehensible. Anyone know where I
>> can find a clear description of how it all works?)
>> --
>> David Given
> --
> Fabio Mascarenhas