Alessio Stalla <alessiosta...@gmail.com> writes: > The key point is that in Lisp "code" does not mean "text" [1]. Code is > made of data structures - lists, symbols, vectors, numbers, ... - and > macros are just functions that operate on those data structures.
Hmm, interesting. One of the things that's drawn me to learning Clojure is the malleability of "code as data," but I hadn't thought about it as potentially running that deep before. Thanks for phrasing that in a way that clicked for me. > In other words, valid code is no longer determined by the reader (i.e. > the parser), but by the compiler and/or the interpreter, that take a > rich data structure as input. The reader is "only" useful to us humans > to enter code into the system. OTOH, the compiler still needs a defined interface. The data structures the reader is able to produce seem like a convenient definition for what data structures the compiler should meaningfully consume. Obviously the reader producing structures the compiler can't consume is useless, but the compiler consuming structures the reader can't produce seems equally problematic to me. It seems like code which doesn't have a textual representation would be much more difficult to reason about. Without guaranteeing a mapping from every valid compiler input to text which causes the reader to directly generate that input, it becomes impossible to inspect what the compiler is actually consuming. -Marshall -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
