[Date Prev][Date Next][Thread Prev][Thread Next]
- From: "Fabio Mascarenhas" <mascarenhas@...>
- Date: Thu, 2 Oct 2008 14:49:09 -0500
more useful, though).
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
compile to Lua's obj.foo (metatables go a long way here).
but maybe your application won't care... sorry for immediately
uglier ones, so you can program in the nicer ones. :-)
On Thu, Oct 2, 2008 at 1:33 PM, Fabio Mascarenhas <email@example.com> wrote:
> On Thu, Oct 2, 2008 at 9:02 AM, David Given <firstname.lastname@example.org> wrote:
>> steve donovan wrote:
>> 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.
> rename the variables so the scopes don't clash, and fix the
> references. It's even easier if you are compiling to a newer
> Implementing all the rest of Lua's semantics is the hard part,
> are in fact quite different. Basically every Lua operation will have
> 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
> 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).
> just as alien to Lua's semantics as the JVM or CLR.
>> reference documentation is largely incomprehensible. Anyone know where I
>> can find a clear description of how it all works?)
>> David Given
> Fabio Mascarenhas