Does anybody here have a experience with Common Lisp as a embedded language (using ECL)? If so, how good is ECL compared to Lua?
+6
A:
I haven't embedded CL before, but I've done it with both Lua and two particular Scheme implementations (Gambit-C and GNU Guile).
Scheme makes a great embedded language in my opinion, because it is flexible and not too bloated. Gambit-C is particularly awesome for this because it allows you to both run interpreted scripts, and also compile your code down to C. In my tests, Gambit-C's generated C code was only a little slower than handwritten C (for example, a particular test that ran 0.030s in C was 0.040 in Gambit!). Gambit also has a really nice FFI (foreign function interface), which is essentially just Scheme with special syntax for writing bindings to C libraries (ObjC and C++ are directly supported also). Gambit also has a very nice repl with some debugging capabilities.
Guile is also pretty nice, and it actually runs faster than Lua (fastest interpreted language that I currently know of -- Guile has made great progress in recent years). But since Gambit-C can compile to really fast code, I generally don't use Guile as much unless I intend to use interpreted code in the final version.
Lua has closures, but you won't get continuations like in Scheme, and you also won't get the macros. It's still possible to do a reasonable amount of functional stuff though. It won't have a fully featured object system (like CLOS in CL), but it does have tables and they can be used to implement both class-based inheritance and prototype-based inheritance quite easily. Also, Lua has an excellent C API that is really a pleasure to work with. It's stack-based, and designed in a way that you don't have to worry about the Lua side of memory management at all. The API is very clear and well organized, and there is a lot of great documentation and example code out there. Lua can't compile down, but it does use byte-code (always -- when you send code to the Lua VM, it always compiles that code down the byte-code first and then runs it).
Now, as for Common Lisp, I think that it would probably not make a very good language for embedding. The reason for this is just that CL is huge. Generally, it's desirable to embed a lightweight language because it's going to be using the platform/libs that you provide to it, and not so much external stuff.
So, I think you can't go wrong with either Gambit-C, Guile or Lua. They'll all really nice. CL is powerful, but I just think it's too big for embedding.
Jyaan
2010-07-13 12:09:29
No- this is wrong. The Lua API is only great if you've only ever done basic things with it. The stack-based interface is simple, but you have to manually remember what's on every place on the stack and compute the indicies yourself. In addition, the OO is terrible- implementation of inheritance is poor, no constructors/destructors, et cetera. Registering UDTs is also pretty damn poor. I hope you never wanted anything but a POD. I've never used any of the alternatives and it may well be the best out there. But my personal experience was that the language is not good or easy to use.
DeadMG
2010-07-13 12:18:42
I wrote a binding to Cairo before and it wasn't hard at all. Just use the userdata type, set __gc for destruction, and call the appropriate luaL_check* function to verify argument types (have to write it for your own types ofc). But I'll agree that it is somewhat more basic and lower level, and if someone wants more than that they'll just need to extend Lua. Regardless, I feel it's a really nice language with a lot of interesting features and is much easier to use than most others.
Jyaan
2010-07-14 05:02:57
@DeadMG: I can't comment on the API, since I haven't used it. I velieve that Lua's OO isn't "terrible"; it's just not provided by default, since that's not the language's goal. But there are lots of good libraries that provide an OO environment if you need it. I recommend ObjectLua for that: http://github.com/sroccaserra/object-lua
egarcia
2010-07-14 07:39:43