Just FYI: I once worked on Lua. It was a while back, when the coroutines were working reasonably well and people were pretty excited. Yep, Lua had (and probably still has) coroutines. They were also trying to replace the collector with a modern copying collector, which was a disaster. It was hard to get working and when it finally did it was slower by a significant margin than the original collector.
At that time, Lua was integrated with Felix, just as today Judy, RE2, Tre, and sqlite3 are integrated with Felix. The problem was that although it's pretty easy to just launch a Lua script, its not at all so easy to communicate across the Lua/C++ boundary. If you do calculations, you have to write functions to set the arguments and fetch the results. You can also extend Lua in fairly well defined ways. Lua is fast and its small, so its easy to justify adding it to say, a game written in C. And more importantly its re-entrant! So you can have thousands of little Lua interpreters floating around. The problem is though, that if you're writing Felix, you already have such a powerful language, its actually easier to implement a mini-interpreter directly than bother with Lua bindings. The result of such a naive effort would not have the performance Lua offers, but it would be much easier to interface (like, there's nothing much to do: you don't need any bindings!). And it would be a lot more flexible than Lua: you can just make it do whatever you want. So in the end I chucked it out. Useful if you're stuck with C. Less useful in a high power language like C++ or Felix because of the cost of doing the bindings and then being stuck with a language which probably doesn't do quite what you want directly. People have also used micro-Scheme's for this purpose. They're a good deal more functional, just as fast, but a bit harder to script: all those dang parens make ME feel queasy, the average game player probably wouldn't have a hope. [Whereas Lua is easier to understand] [of course the Felix compiler uses an embedded Scheme in the parser] Generally speaking all these "mini-string-languages" suck. That includes, for example, C printf formatting and Felix C binding mini-language. They're great, if not very safe, for limited uses but they're never extensible, they're rarely performant, and any binding you need to do soon outweighs the simplicity originally sought (just try to add a new type to C printf to see what I mean). There's nothing wrong with DSLs, the problem is when they're represented as strings instead of a real native code. That's why Felix has the concept of DSSL. Two S there. Domain Specific *SUB* Language. It's also why DSSL support in Python is moderately successful: Python has enough "syntax" to provide semi-seamless integration. This is a particularly vexing issue with *serious* domain specific languages like SQL. Sticking SQL strings in your C/C++/Felix code sucks. I've actually seen a proper, well typed, binding to SQL in Ocaml .. but I bet it was a huge amount of work (and very smart: it actually verifies the Ocaml typing agrees dynamically with the tables in the database by inspecting the data dictionary, before you're allowed to access it). -- john skaller skal...@users.sourceforge.net http://felix-lang.org ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_feb _______________________________________________ Felix-language mailing list Felix-language@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/felix-language
