1–10 of 11 posts
https://stackoverflow.com/questions/36416532/lisp-in-ai-self-modifying-code-and-domain-specific-levels-of-abstraction
I was wondering if this is useful for AI that can modify (improve) its own code. Am I missing something?
Lisp implementations typically give running programs access to the compiler, but that has nothing to do with macros, and then again, other languages do as well.
Currently fashionable machine learning approaches don't generate general purpose code but instead determine the coefficients for a matrix equation. Notably this kind of "program" is guaranteed to finish, which limits what it can do algorithmically, see
https://en.wikipedia.org/wiki/BlooP_and_FlooP
but that kind of program can run efficiently on a GPU or similar device because it is a bunch of repetitive math.
There are some older algorithms like
https://en.wikipedia.org/wiki/C4.5_algorithm
which "learn" rules that look more like ordinary code.
The first thing that comes to mind is the general idea that for any kind of continually improving system (the obvious analogy would be an evolutionary algorithm[0] of some sort) you need a "fitness function" that dictates whether or not the system is, in fact, improving. And defining the fitness function and the representation that maps from your code to the thing you're trying to improve, is often the hardest part.
FWIW, people have explored the intersection of evolutionary algorithms and code generation under the rubric of "Genetic Programming"[1][2][3]. This isn't necessarily the only (or best) such approach, but it's one that has been explored quite extensively and where there is a large body of literature to review. You might find some of that stuff interesting, vis-a-vis this overall topic.
[0]: https://en.wikipedia.org/wiki/Evolutionary_algorithm
[1]: https://en.wikipedia.org/wiki/Genetic_programming
Other languages are similarly dynamic. For instance a Java program can write Java bytecode and pass it to the the defineClass() method of the classloader and then run the code. Currently fashionable machine learning approaches don't generate general purpose code but instead determine the coefficients for a matrix equation. Notably this kind of "program" is guaranteed to finish, which limits what it can do algorithmic…
See also, "Rule Induction"[1].
No. Macros are compile-time. Lisp implementations typically give running programs access to the compiler, but that has nothing to do with macros, and then again, other languages do as well.
No. Macros are compile-time. Lisp implementations typically give running programs access to the compiler, but that has nothing to do with macros, and then again, other languages do as well.
If you can compile code at runtime, then how are you not able to use macros at runtime via the same facility? Macros are just functions that operate on the data structures that define function calls prior to those calls being executed, symbols resolved , etc. So if you’re compiling new code at runtime via eval the that code will go through the same process, including macro expansion.
Earlier quoted context omitted.
If you can compile code at runtime, then how are you not able to use macros at runtime via the same facility? Macros are just functions that operate on the data structures that define function calls prior to those calls being executed, symbols resolved , etc. So if you’re compiling new code at runtime via eval the that code will go through the same process, including macro expansion.
The point was that macros are not special, they don't give you anything more for "self-modification".
No. Macros are compile-time. Lisp implementations typically give running programs access to the compiler, but that has nothing to do with macros, and then again, other languages do as well.
If you can compile code at runtime, then how are you not able to use macros at runtime via the same facility? Macros are just functions that operate on the data structures that define function calls prior to those calls being executed, symbols resolved , etc. So if you’re compiling new code at runtime via eval the that code will go through the same process, including macro expansion.
calling (eval (generate-some-code)) does already execute newly generated code at runtime.
Earlier quoted context omitted.
The point was that macros are not special, they don't give you anything more for "self-modification".
Macros are special in the sense that they are expressly intended to modify code. I take your implied point that at runtime there is not really a difference between a function designed to rewrite code data structures and evaluate them vs calling macroexpand and using a predefined macro. But it’s going to be more concise at least to do the latter. It’s also probably the case that when people talk about lisp macros they…
Macros are intended to transform code. They are designed such that in compiled code the transformation is only done at compile time.