On 4 Mag, 01:34, Chris Perkins <chrisperkin...@gmail.com> wrote: > On May 3, 5:22 pm, André Thieme <splendidl...@googlemail.com> wrote: > > > Some of the limitations: > > 1. (defmacro x [] `(let [a# ~(atom 0)])) > > > 2. (defmacro y [] `(let [a# ~(comp inc inc)])) ; from that link > > > 3. (defmacro z [] `(let [a# ~((fn [x#] (fn [] x#)) 0)])) > > > All three calls fail, (x) and (y) and (z). > > I see no plausible reason why it *should* be that way. > > I do - because most of the time, embedding an object in code is > accidental, caused by messing up the quoting and unquoting. I would > prefer that evaling something that cannot be produced by the reader be > an error. > > I can see that in some cases, having eval pass unexpected types > through unchanged can be useful, but I think it would be much more > common for it to result in hard-to-debug errors, especially for > beginning macro writers.
Code-is-data is the quintessential feature of Lisp. That some code cannot be produced by the reader is, at most, a limitation of the reader, not a reason for making that code illegal. It can, sure, be a source of errors, but no more than forgetting to quote or unquote a symbol in a macro expansion already is. Including closures in compiled classes is not trivial, but still technically doable, and since as André demonstrated that it's the basis for certain advanced macro techniques, imho it's a feature that should not be missing from a powerful, stable, widely used Lisp like Clojure. Alessio -- 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
