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
