[From WhyLisp]
I still fail to understand, though, how a Lisp compiler can interpret data *cough* code which is created at runtime, at the same speed as original compile-time code. I suppose I could look it up somewhere. -- MatthewAstley, DeleteWhenCooked
Well, if it is CommonLisp the compiler is part of the runtime. So you can dynamically create functions, compile them (or not) and run them just like any other function...
Thanks. I thought it was more of a "translate to CeeLanguage, pass through GCC" kind of thing.
While there are projects to implement CL on top of a C compiler (see ECL), that behaviour is the exception, not the rule. There are, however, very good CL compilers (see CMUCL for a free one) which will compile CL to AssemblyLanguage, generally within a factor of 2 of a good optimizing C compiler. This is pretty amazing, considering how much more power you get in CL compared to C. To put it another way: a lot of people like languages such as tcl/perl/python, because it's abstractions let them code much faster than they would in C. However, the "abstraction penalty", if you want to call it that, is sometimes quite high, often a couple or even three of orders of magnitude. So often people optimize by going back and writing critical bits in C or C++, which is a bit of a mess. With CL, you get more power and abstraction than these languages, and with appropriately written code you can have very little penalty. Why this hasn't sunk it for more people I am not sure (actually, that's a fib - I have some ideas). [WhyNotLisp?]
Could someone explain how this is done. For most OSs you can't execute anything is the data segment, so how do you execute dynamically created code? Mark it as executable.
Also see JustInTimeCompilation.