4 ms·

LISP macros are compile time self modifying code. So are many other macro systems.

benj111 8y ago
Yes, but so are C macros. I mentioned lisp machines in a prior answer, I don't know enough about them to say whether they would allow self modifying lisp code though.
kazinator 8y ago
Lisp macros are not self-modifying code in any shape or form. They calculate new syntax tree fragments from existing syntax tree fragments, often using purely functional techniques (no mutation at all, not even of local variables in the macro). The compiler internals of pretty much any programming language do similar tree to tree transformations: just not ones that the program itself can specify as part of its code. We don't call C self-modifying because a for(;;) loop structure was changed by the compiler into if/goto with generated labels, and then changed again into assembly code. A macro that mutates the input source code on which it operates wouldn't pass a code review in any competent Lisp shop. It can happen. For instance (setf (car '(1 2)) 2) is self-modifying code; it tries to replace the 1 with a 2, and that 1 is embedded in the program code itself, in a literal list. This is undefined behavior according to ANSI CL, very similarly to how "abc"[1]++ (modifying a string literal) is undefined behavior in C. Note that this code isn't implementing a macro. I've never heard of compiled Lisp object code being mutated. Lisp programs as such can be self-modifying; a common example of that is updating while running: loading new versions of existing modules, replacing old functions with new ones. That doesn't involve modifying code.
- SomeHacker44 8y ago
  While your use case (creation of new syntax tree in a deterministic fashion) is definitely the most common use case of Common Lisp macros - it is not the only one. Common Lisp macros are literally code executed at compile time on the source AST. It needs not make a deterministic change to that AST, needs not be side-effect free, and needs not use only and solely the context of its input AST to output the final AST. Doesn't mean I suggest doing this, but please do not sell unhygenic CL macros short. :) In fact, in CL one has to go to some lengths to be careful to make macro outputs "safe."
  - lispm 8y ago
    If macros are running at compile time, then we don't think that this particular code is self modifying. If we run code in a Lisp interpreter, then one can write self-modifying code. It's possible to get visible effects. It's also possible to use it during debugging code.
  - kazinator 8y ago
    Regardless of any lack of referential hygiene, or reliance on side-effects such that the same piece of code is not expanded the same way twice, CL macros must not mutate the input AST, period. It is undefined behavior, and easily avoidable.

Yes, but so are C macros. I mentioned lisp machines in a prior answer, I don't know enough about them to say whether they would allow self modifying lisp code though.

kazinator 8y ago

Lisp macros are not self-modifying code in any shape or form. They calculate new syntax tree fragments from existing syntax tree fragments, often using purely functional techniques (no mutation at all, not even of local variables in the macro). The compiler internals of pretty much any programming language do similar tree to tree transformations: just not ones that the program itself can specify as part of its code. We don't call C self-modifying because a for(;;) loop structure was changed by the compiler into if/goto with generated labels, and then changed again into assembly code. A macro that mutates the input source code on which it operates wouldn't pass a code review in any competent Lisp shop. It can happen. For instance (setf (car '(1 2)) 2) is self-modifying code; it tries to replace the 1 with a 2, and that 1 is embedded in the program code itself, in a literal list. This is undefined behavior according to ANSI CL, very similarly to how "abc"[1]++ (modifying a string literal) is undefined behavior in C. Note that this code isn't implementing a macro. I've never heard of compiled Lisp object code being mutated. Lisp programs as such can be self-modifying; a common example of that is updating while running: loading new versions of existing modules, replacing old functions with new ones. That doesn't involve modifying code.

SomeHacker44 8y ago
While your use case (creation of new syntax tree in a deterministic fashion) is definitely the most common use case of Common Lisp macros - it is not the only one. Common Lisp macros are literally code executed at compile time on the source AST. It needs not make a deterministic change to that AST, needs not be side-effect free, and needs not use only and solely the context of its input AST to output the final AST. Doesn't mean I suggest doing this, but please do not sell unhygenic CL macros short. :) In fact, in CL one has to go to some lengths to be careful to make macro outputs "safe."
- lispm 8y ago
  If macros are running at compile time, then we don't think that this particular code is self modifying. If we run code in a Lisp interpreter, then one can write self-modifying code. It's possible to get visible effects. It's also possible to use it during debugging code.
- kazinator 8y ago
  Regardless of any lack of referential hygiene, or reliance on side-effects such that the same piece of code is not expanded the same way twice, CL macros must not mutate the input AST, period. It is undefined behavior, and easily avoidable.