Re: JavaScript to Lua compiler

[Chetan Singh <chetan_dhillon@...>]

Hi fabio, Thanks fo pointing me to MiniJoe. I will take a look. Yes I was looking for JavaScript -> Lua assuming that that Lua VM would be faster than any other JavaScript engine that is avaialbe for J2ME devices. 
Regarding your comment on running JacaScript in Kahlua, once it is compiled into Lua (off-device lets say on a server), it would run as fast as Lua code on J2ME. Right?

I am not very much familar with either language so don;t know how much work is involved in translating JS to Lua. That is why I am looking for a tool/complier.

thanks much for you help
CHetan


--- On Thu, 10/2/08, Fabio Mascarenhas <mascarenhas@acm.org> wrote:

> From: Fabio Mascarenhas <mascarenhas@acm.org>
> Subject: Re: JavaScript to Lua compiler
> To: "Lua list" <lua@bazar2.conectiva.com.br>
> Date: Thursday, October 2, 2008, 12:49 PM
> Oops, just noticed it's JavaScript->Lua, not the
> reverse (if the
> intention is runninng JavaScript on J2ME maybe
> http://minijoe.com/ 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 obj.foo
> compile to Lua's obj.foo (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
> <mascarenhas@acm.org> wrote:
> > 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
> >