{"by":"wooby","id":4699056,"kids":[4701476],"parent":4697874,"text":"Your example is nonsense. Clojure's keep is based on lazy sequences instead of concrete lists, and is also optimized for performance.<p>That said, you raise a point that occurred to me recently, and it relates to Clojure's literal representation of data beyond lists and your point about the \"ruined magic\".<p>In most Lisps, the only evaluation semantic is that of the \"operator form\": a list of operator car and arguments cdr, both of which are evaluated themselves.<p>Clojure, however, adds an evaluation semantic for its data literals. Consider this code:<p>{(+ 1 2) (+ 3 4)}<p>It results in the map {3 7}, but where is the \"operator form\" that caused the top-level evaluation?<p>In Lisps with reader macros, an expression like above boils into code resembling (hash-map (+ 1 2) (+ 3 4)), a classic \"operator form\", which is then evaluated.<p>In Clojure, however, which does not provide reader macros, there is no intermediate list representation of the expression accessible to the programmer. Effectively, Clojure adds evaluation semantics to Lisp beyond \"operator forms\": data literals evaluate their contents, and qualify in many ways as \"special forms\".<p>I have run into at least one implication of this design having to do with the structural representation of Clojure code. With a \"classic\" Lisp, an IDE or editor is empowered to present to the user any representation of the code, and can convert it to Lisp expressions arbitrarily the same way reader macros do.<p>With Clojure, this type of \"skinning\" is harder, because IDE-like navigation of data implies ordering. The ordering exists in the character-wise representation of a map like {3 4} but not in its evaluated counterpart.","time":1351192913,"type":"comment"}