On Thu, 15 Jul 2010 08:10:55 -0700 (PDT) Quzanti <quza...@googlemail.com> wrote:
> Hi > > Here is my sorry tale > > http://gist.github.com/477069 > > I am not sure if this could be my misunderstanding of macros or the ~ > idiom > > Anyway if you spell out a record structure to a macro then you keep > the Record information, even you call a function which spells out the > structure then the records get turned into PersistentArrayMaps? > > I first discovered this behaviour on an early July build, but it is > the same in the 1.2 Beta > > Any clues? > I think I see the problem. In the first case, the ~ (unquote) is causing the result of evaluating the (company-fn) (which is a record) to be inserted at macro expansion time. Since defrecord's implement IPersistentMap, it appears to get converted to literal maps in the result of the macro expansion. Then, when you *evaluate* the result of the macro expansion, the literal map evaluates to itself and gets returned as a plain old map. In the direct case (explicit-var), you're not inserting a record into the macro expansion, but rather a form for constructing one, because it's not unquoted. Then, when that is evaluated *after* macro expansion time, it constructs the record instance. The key insight is that (Company. ...) is not actually a "literal" record, it's a call to a constructor, which like all function calls, is a list. In essence, var-from-fn constructs the record (which is converted to a map literal) at *macro expansion* time, while the second one constructs the record at *evaluation* time. If you force evaluation of the (Company. ... ) form at expansion time by unquoting it in explicit-var, I imagine they will both return regular old maps via the same quirky conversion behavior. What I don't know is, is it meaningful for a macro to expand to something that contains stuff that couldn't ever appear in the output of the reader, like instances of user-defined types, or even Java objects for that matter? What is the expected behavior here? To me it seems like that the behavior it exhibits here is an implementation artifact. -Kyle -- 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
