syntax quote effectively does that it, it rewrites your forms as a series of calls to various sequence functions like concat and in the shuffling it loses metadata.
On Mon, Oct 24, 2011 at 12:43 PM, Alan Malloy <a...@malloys.org> wrote: > I'm not sure I buy that. If I write my macro as (defmacro call [f arg] > (list f arg)), which I did consider doing for this post, the same > thing happens. Perhaps you could explain what you mean? > > On Oct 24, 12:37 pm, Kevin Downey <redc...@gmail.com> wrote: >> it's not a macro issue, it's a syntax quote issue >> >> >> >> >> >> >> >> >> >> On Mon, Oct 24, 2011 at 11:54 AM, Alan Malloy <a...@malloys.org> wrote: >> > I'm struggling with a basic feature of how macros behave. I understand >> > how the >> > problem arises, and I can cobble together my own fix in the specific >> > places >> > where it's causing me trouble, but it seems like a prettier, more >> > general >> > solution would be desirable. Below is a brief transcript demonstrating >> > the >> > problem. >> >> > user> (defmacro call [f arg] `(~f ~arg)) >> > #'user/call >> > user> (let [f inc] (.intValue (f 10))) >> > Reflection warning, NO_SOURCE_FILE:1 - reference to field intValue >> > can't be resolved. >> > 11 >> > user> (let [f inc] (.intValue ^Integer (f 10))) >> > 11 >> > user> (let [f inc] (.intValue ^Integer (call f 10))) >> > Reflection warning, NO_SOURCE_FILE:1 - reference to field intValue >> > can't be resolved. >> > 11 >> >> > I want to typehint the return value of f, so I put metadata on the >> > form >> > representing a call to it. But if a macro gets involved, there's an >> > "intervening" form that ignores its metadata and returns a new list of >> > '(f 10) >> > with no metadata. Thus the compiler has no idea I ever wanted to give >> > it a hint >> > about the type. >> >> > There are two solutions that are simple enough for me to apply: >> >> > (1) At the call site I can bind the result of (call f 10) to a local >> > named i and >> > then put the typehinting metadata on that >> >> > (2) I can edit the call macro to return a form with the right >> > metadata: >> > (defmacro call [f arg] (with-meta `(~f ~arg) (meta &form))) >> >> > Both of these work, but they seem awful. If the language specifies >> > you're >> > supposed to be able to typehint expressions as well as named bindings, >> > it's both >> > unintuitive and quite inconvenient that most macros do not "respect" >> > this >> > behavior by default. And many macros I don't have enough control over >> > to make >> > this change. For example, the whole issue arose when I was trying to >> > hint the >> > result of a (for ...) as a java.util.List. It ignores my metadata and >> > returns a >> > new form; and I certainly can't go edit its source, so instead I have >> > to bind >> > the result in a let, for no reason other than to typehint it. >> >> > It seems to me that it would be nice to have macros automatically >> > include, on >> > their result forms, the metadata from their input &form. Of course, >> > macros may >> > wish to add metadata as well, so the two maps should probably be >> > merged. However, there are certainly some problems with this approach: >> > for >> > example if a macro wants to return something that can't suppport >> > metadata (like >> > an Integer), the compiler needs to be careful not to try to include >> > it. So I'm >> > hoping the community can comment on whether this feature would be >> > useful, or >> > whether there are fundamental problems with it that I haven't >> > foreseen. Is there >> > a reason this can't make it into a future version of Clojure? >> >> > -- >> > 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 >> >> -- >> And what is good, Phaedrus, >> And what is not good— >> Need we ask anyone to tell us these things? > > -- > 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 > -- And what is good, Phaedrus, And what is not good— Need we ask anyone to tell us these things? -- 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
