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

Reply via email to