Classically, "code is data" is used upfront, in creating macros that manipulate Lisp code as data, before sending the result to the interpreter or compiler like normal functions and data. Ideally you develop your own Domain Specific Language that provides power in expression and execution for what you're trying to do.
As implied in other answers in the subthread, nowhere in this paradigm does random input data get treated as something that can safely be executed. READ in Lisp Machines is mentioned because reader macros like #. allow data in the form being read to be evaluated, which in this domain is an obvious big no-no.
As early as 1983, I think earlier, it was recognized that things like eval servers were a bad idea if accessible by the outside world.
So, I am really just a beginner. To me it seems to be the case that attackers may find a way to break out of a particular data processing instruction and execute arbitrary lisp code.
If you say, this can't be so, you may well be right...
As I understand it, unless you're using a Lisp with an reader macro that calls eval, or your code calls eval, and you allow arbitrary input into that code while running vs. loading/compiling, it's just not going to happen.
As implied in other answers in the subthread, nowhere in this paradigm does random input data get treated as something that can safely be executed. READ in Lisp Machines is mentioned because reader macros like #. allow data in the form being read to be evaluated, which in this domain is an obvious big no-no.
As early as 1983, I think earlier, it was recognized that things like eval servers were a bad idea if accessible by the outside world.