3 ms·
What you want in this kind of situation is for those symbols to be internal objects that cannot be written. Or perhaps symbols in a private system package, e.g.
by kazinator 2y ago
What you want in this kind of situation is for those symbols to be internal objects that cannot be written. Or perhaps symbols in a private system package, e.g.:
(sys:lit sys:clo nil (x) (+ x 1))
No program using symbols in the ordinary namespace will produce this object by accident. It has to use the sys: stuff and when it does that, the language specification can say that it's sticking the proverbial fork into the proverbial toaster.
- lisper 2y agoThat doesn't help at all. These symbols don't have to be produced by the reader. All you need to do to get access to these symbols is to call FN once. That gives you a list whose first element is LIT and second element is CLO. So all you need to "stick a fork" in the Bel toaster is to be able to call FN and XAR.
- kazinator 2y agoYes. In a nutshell, the problem is that (consp x) being true does not rule out (functionp x), which it should. (Unless consp is hacked in an unspeakable way.) In a real implementation, you'd want a new kind of cons cell with a separate type tag so that it fails consp. It's okay if car and cdr like it.
- lisper 2y ago> (consp x) being true does not rule out (functionp x), which it should Exactly. That's what "punning lists" means. > It's okay if car and cdr like it. That's arguable. But the real problem is if XAR and XDR accept it. Functions, however they are implemented, should not be mutable. That way lies madness.