On Wed, 4 Aug 2010 14:58:46 -0400 Andrew Boekhoff <boekho...@gmail.com> wrote:
> Hi, > > > because the symbol's namespace is then nil, and you still can't > > tell if they're shadowing it with a let binding, or have renamed it > > with :as. > > > > If the namespace is nil then its either been :used or :required. > You could check ns-refers to see if its been :used. If its been > shadowed the symbol will appear in &env. But, as you suggested, > checking for the var may be easier and sufficient as well. I think this is the way I will go. I came across &env earlier today and that gave me some ideas, although I don't know if I need to get that complex. Maybe it is sufficient to have the assumption it will always be a straightforward call where they use the symbol as it appears in their namespace. So long as I can identify that, I think it will be sufficient. > That said, neither method is really composable. If the symbol > usually represents a normal function, the user may wrap it in a > helper or otherwise use it in a way that the symbol is not visible. > In that case a macro will never be able to find it. If they do that then I'd actually prefer the macro not attempt to transform it, because the semantics would be ill-defined, so this is actually perfect. All I'm after is to allow the user to be able to control my library's effect on his/her namespace in the ordinary manner, and still let my macro be able to identify calls to that function in a reasonably robust way. Since the function, used outside the macro, is actually useful in and of itself, having it be unnecesarily assymetrical (called one thing in the macro and another thing outside it) is something I'd like to avoid. Thanks for your thoughts. -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
