lua-users home
lua-l archive

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


On Thu, Oct 2, 2008 at 9:02 AM, David Given <dg@cowlark.com> 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
> dg@cowlark.com
>

--
Fabio Mascarenhas