Lisp implementation that compiles to Lua code
github.com/meric/l2lPosted Apr 13, 2012, 12:35 PM UTC
3116
github.com
I was wondering where all the compiles-to-Lua languages were. I like most of Lua except the syntax.
I was hoping for CoffeeScript for Lua, but this is cool too.
4
Perhaps you might peruse MoonScript then. Personally I prefer vanilla Lua, but it's an interesting project.
3
Oh hey, neato. Thanks!
3
Dang. The compiler is written in Lua?
That is impressive. (I was expecting it would be a CL program..)
1
Why do this when there's embeddable common lisp and several small Scheme and Lisp implementations?
Because Lua is often used as a scripting language, meaning you are not able to used anything other than Lua.
Probably because LuaJIT is very fast, and still embeddable.
Because people say that, but it always turns out that Lua is easy to embed and those are a nightmare - and that's once you skip over the GPL licensed options which aren't useful for most of us.
On the other hand, if you can point me at Scheme or Lisp that meets this list of criteria, I'll owe you a beer if I ever run into you
GPL Linux-only and GCC only options are easy to find. Unless you're a GNU fanatic (in which case you already hate me) that's not sufficient.
Lua wins on all of those. I've never seen a Scheme or Lisp get more than 3 points, and they're never the same three.
I've been evaluating embeddable lisps recently and had lots of issues that make me welcome something like this.
First of all, just building most is a giant hurdle, forget about adapting their convoluted build systems to cross compile.
Secondly, their basic APIs have been a mess. Just give me a clean C API prefixed with your_lisp_name. Instead, you'll more often than not get something that's exposed 1/3 with C, 1/3 with CPP macros, and 1/3 with direct field access in obscure structs. Forget about consistency: string_length returns a sexp that you convert to a C type, but vector_length returns a C type directly. Of course, there's no way to find out because one is implemented as a macro and has no type annotations. Some functions take an env, some don't. Consider chibi's sexp_vector_length(sexp vector) vs. sexp_length(sexp context, sexp list).
Thirdly, runtime behavior and feature support is a mess. They all implement different pieces of the standards. Tinyscheme dies with an out of memory error in a simple loop that creates objects that nothing's holding on to. Calling (gc) does nothing. Chibi-scheme has a weird set of macros for declaring that you want to pin N variables on the stack, actually pinning N variables, and then releasing N variables. What happens when they're not on the stack? You have a separate retain/release style pair of functions. Sounds good. Later I find out that _release for some reason is prohibitively expensive in a trivial test case.
Embeddable lisps are a mess.
The real question is why would anyone use those CL and Scheme implementations when they're basically shit compared to LuaJIT and even the official Lua VM?
yah, why did people implement lisp that runs on computers in the first place when there's assembly? people do meaningless stuff all the time.
I think OMouse's point was that there seems to be little practical purpose for translating lisp to lua when there are already native lisp implementations for the platforms this would (assumedly) target. Also, though it might not be fair to compare Lua to SBCL (since SBCL isn't really small or embedded), Steel Bank Common Lisp seems to have a much better performance profile than Lua in The Computer Language Benchmarks Game.
You should be comparing with LuaJIT, not Lua, if you care about performance.
LuaJIT is an implementation, so the correct argue on is that Lua has faster implementations than CL does.
It definitely has better performance. What was really interesting is that the comparison between SBCL vs Lua and Racket vs Lua is similar.
[deleted]
Oh no, I'm not against that, I've implemented my own Lisp or attempted to before :-P but this is Lua that's being targeted, there's not really any point in that. It makes more sense to implement Lua to target Guile's VM bytecode (I think they've gotten JavaScript to compile to it) or to target SBCL (CL-Python does this, it's a Python implementation on top of SBCL).