Colony, an experimental JavaScript-to-Lua compiler
github.comHey all, I'm posting this to HN to see if there's any interest in a full-fledged JavaScript port to Lua. Colony right now is a proof-of-concept, but there might be a real use case out there for embeddable JavaScript where solutions like V8 would simply be too large.
Since it's a source-to-source compiler, you can use Colony generally wherever Lua source is required. For example, I was able to follow the beginners tutorials of the Corona SDK (http://www.anscamobile.com/corona/, a cross-platform mobile SDK that uses Lua) by programming CoffeeScript instead, which was surprisingly fun.
Interesting idea and possibly worth tossing out to the World of Warcraft addons/scripting community (single largest Lua end-user install base in the world, I believe) as well?
BTW, the name seems a bit tacky for a language developed in Brazil given the colonial history. Was there another reason for naming it that I've missed?
Hmm, you could target iphone wax https://github.com/probablycorey/wax to make a coffescript dev environment for iOS. Wax is a really nice environment.
Using javascript as a language instead of Lua for scripting though seems odd, as Lua is pretty easy to use instead.
If you like CoffeeScript you should try out http://moonscript.org
CoffeeScript inspired syntax that compiles right to Lua.
Lua is a great language. I personally would rather go the other way and use Lua instead of JS in the browser.
This is cool though from a hacking perspective. Good work.
In which cases would anyone need:
- to write code in JS rather than in Lua;
- and run the result on a platform which supports Lua but not JS?
Except in a Dilbert-like situation, where a clueless middle manager decides that using a dirty hack is safer than letting JS programmers take the 2 days it would take them to become very proficient in Lua, I can't think of one.
Many C applications use Lua as an embedded scripting language. This program would be very useful if the developers of the application wanted to extend scripting support to Javascript (and compile-to-JS languages) without having to modify their C code.
But a transcompiler will always be a kludge, at least when the target language hasn't been designed as a bytecode.
Most importantly, I'd bet that the intersection of developers who:
(1) can write good software; and
(2) Can write decent JS code, but can't become proficient in Lua within a couple of days;
is mostly empty.
But if they are developers why would they not want to modify their own C code (to add an embeddable JS interpreter?)
js interpreters are not as friendly as lua for embedding.
Exactly, I've worked with the Lua C API before, it was fairly easy to use. I've looked at the V8 API before. Compared to Lua, it is far more complicated.
The fun thing about transpilers is that you can chain them together. Waiting to see some C stuff ported to Lua using Emscripten via JS.
Perhaps the best way to write a transpiler so there's no bugs is to write two of them at the same time, i.e. in this case Lua-to-JS and JS-to-Lua. Maybe it's easier to catch bugs.
This mirrors the idea of writing a compiler for a new language in itself as soon as possible.
Get a Clue: http://cluecc.sourceforge.net/
Decent timing from LuaJIT1 when it was generating "dirty" Lua bytecode.
I remember google's dart that compiled to javascript which ran 7% as fast as hand-written javascript. I wonder what the performance for this will be compared to handwritten lua? I've tried wrapping everything into tables like this in lua, and there definitely is a performance penalty.
I guess programmers will always be programmers. "Ooo look, this year CPU speed has quadtripled! Let's make a compiler for X to Y which will reduce performance by only 75%; It means you can run it at the same speed as running hand-written Y last year!"
I'll cringe when I see someone creating a WoW addon using this.