begin quoting David Brown as of Sat, Jan 12, 2008 at 01:48:23AM -0800: > On Sat, Jan 12, 2008 at 12:26:07AM -0800, SJS wrote: > > >>So in a sense "macros" (or at least self modifying code) even predates > >>Fortran and Lisp! > > > >A macro system is VERY useful when writing assembly. > > But we need to be clear that macros are something completely different than > self modifying code.
Yup. Macros, in general, emit code. Here's the macro, here's the parameters, and boom... it's as if you had typed in all this code... > General macros are code that runs at compile time. With assembly, the > macros are invoked during the run of the assembler. Yup. > Since lisp compiles incrementally, this can be a little unclear. Um, that's not a /requirement/ for LISP, is it? > The macro > is never modifying existing code. It takes a piece of uncompiled code and > modifies it before the final compiler ever sees it. LISP does make it easy to modify running code, right? Just not via the macro system. > This is again, also very different from 'eval'. > > An easy way to distinguish these is to think of how a cross compiler would > work. If I had a lisp cross compiler, any functions that are invoked as > part of a macro would have to be compiled or interpreted on the host. The > resulting code would then be compiled for the target system. Yup. > Having something like 'eval' allows you to get the same effect as could be > done with self-modifying code, but with a lot more safety, since the > compiler/interpreter is helping you. Macros won't help you modify the code > that is running. Well, technically, you might make some macros that could help. . . :) -- Any language that comes with an eval function Must be able to disable it at some junction. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
