|
|
|
|
|
|
by p4bl0
4960 days ago
|
|
|
It's not really necessary to second you, but I'd like to add that "code as data" is more real in Racket than is CL since code is not just the AST, it's also (as you point out) location and more importantly, context. In this setting Racket' syntax objects are more "code as data" than "code as sexp" as it is in CL will ever be. |
|
|
* Lisp made the first giant step of having code representable as data for meta-programming, and chose sexprs to do so
* Common Lisp came later, and made the important step of requiring this representation, which means that in every CL implementation you're required to have the code as data aspect
* But the flip side of this is that CL hard-wires just sexprs, it forbids an extended type, which means that you can't get anything more than sexprs (without resorting to "extra properties" hash table tricks)
* Meanwhile, Scheme (R5 and others that have only `syntax-rules') took a step back by specifying only rewrite rules which can be implemented in any way an implementation chooses
* But some Scheme implementations did use sexprs, but since they need to encode more information (lexical context) they extended them into syntax values (note that some Scheme low-level macro systems try to present users with a simplified interface where user code sees just the sexprs)
* Later on, Racket took further steps and enriched its syntax values with "more stuff"
* R6RS got closer to this too, by adopting the syntax-case system (but some people had issues with "wrapping" symbols, since you can't do that with the hash table trick)
* And finally, R7RS (the "small" version) is going to take a step back into the R5RS days. (And in the "big" language it looks like they'll adopt one of these systems that try to keep the sexpr illusion.)