lua-users home
lua-l archive

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

I've pushed a fix for that problem. Basically, now I'm wrapping each block that can loop in a _javascript_ function that is immediately executed. This simulates the same effect in Lua as far as I can tell. Basically, the generated code would roughly be this...

function main()
 for (var i = 1; i < 10; i++) (function () {
   var j = i;
   f(function() { print(j); });

This was actually how it was originally done, but I thought it wasn't necessary if I named variables properly. Thanks for the tip.

On Wed, Nov 16, 2011 at 8:13 PM, Maximilian Herkender <> wrote:

On Wed, Nov 16, 2011 at 4:44 PM, David Given <> wrote:
On 17/11/11 00:12, Maximilian Herkender wrote:
> Coroutines are not yet supported, but they might be able to be recreated
> using web workers, otherwise it might be possible to fake them. I don't
> know enough about coroutines or web workers right now to say for sure.

They can't be --- coroutines all exist within the same Lua universe and
so can access each other's variables, while web workers exist within
different _javascript_ universes and can't (and can only communicate with
each other via messages).

That's disappointing, it seems like "real" coroutines can't exist in _javascript_ then.

The only way of doing coroutines would be to automatically invert the
control flow of the code, where, e.g., all _javascript_ code becomes
threaded via a dispatcher based around the _javascript_ event loop, so you
can return to the event loop at any point in the code. It's all quite
doable, but deeply non-trivial (particularly if you want it to be
efficient). OTOH it would be a killer feature. _javascript_ being
single-threaded is one of its major flaws... er, amongst its many major
flaws, this is one of them.

My goal with this project was to create a very direct Lua->_javascript_ translator, the fastest possible solution to this problem I could think of. In many ways using emscripten was the original solution, and I created this to be an alternative to compensate for how slow it is. I would love to see an alternative to lua.js that fully emulating a Lua VM, without sacrificing as much speed as emscripten does, but as far as I can tell it does not exist yet.

(ECMA were actually contemplating adding coroutines to a recent
_javascript_ version. They eventually decided not to, because it would be
'too complicated'. Pfah...)

Ugh. This is why I like Lua much better.

> That way the block-level scoping in Lua will behave the same in every
> experiment I've tried. I'm not completely confident the behavior of
> variables is the same as in the Lua VM, but I haven't found anything
> that suggests it is different.

There's one big gotcha with _javascript_ vs. Lua when it comes to closures:

In Lua:

function main()
 for i = 1, 10 do
   local j = i
   f(function() print(j) end)

...each closure passed to f gets a different j (with a different value).

In _javascript_:

function main()
 for (var i = 1; i < 10; i++)
   var j = i;
   f(function() { print(j); });

...each closure passed to f gets the *same* j (which means that once
main() exits, it will have the value 10).

This is because _javascript_ variables are scoped at the function level,
regardless of where the var statement actually is.

Shoot, you're right. I thought redeclaring (in this case "j") each time had the same effect. It doesn't. I'm going to see if there's a way around this.

┌─── ───── ─────

│ "Never attribute to malice what can be adequately explained by
│ stupidity." --- Nick Diamos (Hanlon's Razor)