3 ms·
The insight that "code is data" and should be viewed as such is very well treated by lots of literature/languages. Tons of languages support "eval" and building
by banachtarski 10y ago
The insight that "code is data" and should be viewed as such is very well treated by lots of literature/languages. Tons of languages support "eval" and building an AST is really not that difficult. I think SICP might be a popular entrypoint to interpreters but probably not the best.
- throwaway7645 10y agoPerl supports eval like lots of languages because data CAN be code. It's only in homoiconic languages like Common Lisp, Scheme, Racket, Clojure, and Rebol/Red that code IS data. Just because you have EVAL doesn't make it a 1:1 relationship and that makes a big difference. If your code/data is just a big AST, then macros are trivial and that prompts you to write DSLs...etc.
- cutler 10y agoIt's also the concept of the reader which differentiates lisps from languages which attempt the same thing with eval.
- banachtarski 10y agoRight, I'm not even just talking about code as data in a homoiconic sense but literally just, code is a bag of instructions (jumps, load, store, add, etc) regardless of if your language is homoiconic or not. Maybe the point that can be made is that exposure to a homoiconic language earlier helps bridge this gap faster?
- throwaway7645 10y agoAight we're on the same page now. Yea it's all the same instructions under the hood anyway at some point.