That would be relevant if I were talking about losing metadata on arguments to the macro, say like (call .length ^String (identity "test")). But I'm talking about metadata on &form - syntax-quote never sees that at all, so there's nothing for it to lose.
On Oct 24, 12:50 pm, Kevin Downey <redc...@gmail.com> wrote: > 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
