|
|
|
|
|
by anonjon
6007 days ago
|
|
Right, that is the reason that there is such a huge difference between the runtime for eval between the languages. Macros do slow down eval if you are doing macro-expansion. They are complicated enough that normally you do not write (or expect) them to expand quickly. This is obvious because macros and fexprs are much different. Overall, macros can speed up your program because you are allowed to do certain calculations ahead of time, if you are clever about it. I am not saying that you should avoid eval completely, I am just saying that it shouldn't be your only tool. And when you do use it, if you put it in a tight loop, you are probably doing something wrong. The main alternative that comes to mind for me is function passing. There is a lot that you can do with function passing that overlaps with eval, except the function passing version will be safer and faster. We agree that is one of the most powerful, most fun aspects of using lisp (the power is what makes it fun!). I also hope we agree that the frequency of its use should be the inverse of its power. |
|
When code is running using EVAL and an interpreter, macros can be expanded once and then the expanded code is used next time. For example in a loop it is not necessary to expand a macro each time it is used.
If one needs to EVAL new code all the time, then one may ask oneself if that is really necessary. For example if one is doing some kind of genetic programming. Otherwise it is basically a programmer error to do so.
I haven't seen any convincing example where it is really needed. My Symbolics Lisp Machine (which comes out of the MacLisp tradition, which had FEXPRs) got only limited FEXPRs (can't be compiled, can only be used at the top-level). Still the developers who had extensive FEXPR experience with Maclisp, were able to write the compiler, the garbage collector, the graphics driver, the window system, the network system, compilers and interpreters for various languages, text editors, mail clients, mail servers, and much more without using FEXPRs.