Gary, maybe I'm misunderstanding you, but cljs.core/resolve-var doesn't contradict your "the macro system has no knowledge of the CLJS compiler internals" stance? What's the intent of that function (given that trying it in my original example doesn't seems to be capable of resolving the var)? It can access the vars defined in the CLJS side?
Saludos, Nahuel Greco. On Sat, May 31, 2014 at 11:13 AM, Gary Trakhman <[email protected]> wrote: > The other piece of the puzzle: > > cljs.core/resolve-var is in a CLJ namespace and uses compiler state: > > https://github.com/clojure/clojurescript/blob/master/src/clj/cljs/core.clj#L681 > > > On Sat, May 31, 2014 at 10:10 AM, Gary Trakhman <[email protected]> > wrote: > >> The key is in what you think you mean by 'available at compile-time'. >> >> How could this be the case? >> >> The macro system has no knowledge of the CLJS compiler internals, and the >> CLJS compiler does not try to project its state onto the clojure namespace >> system. >> >> However, CLJ macros can return symbols in data that will eventually make >> sense in a CLJS context, without having any knowledge of that CLJS context, >> which is the case. >> >> >> On Sat, May 31, 2014 at 9:47 AM, Nahuel Greco <[email protected]> wrote: >> >>> Thomas, this is an isolated test, the real case was creating a defmulti >>> macro wrapper and a defmethod one, so in the mydefmulti macro I attach >>> some metadata to the var defmulti defines and then I fetch it in the >>> mydefmethod calls (by using resolve), all in compile-time. This works >>> perfectly in the pure CLJ case but not in the CLJS one. The nested def >>> in my original example was an extra experiment, because for testing I need >>> to put nested def's inside deftest's, but note the problem manifests >>> also with the top-level def, so nesting the def is not really the >>> problem here. >>> >>> The vars needs to be defined on the CLJS side, I thought they were >>> available at compile-time for the macros like in CLJ. So if standard >>> resolve and his friends doesn't work, there is a way using the analyzer >>> and &env from the macro to get that CLJS compile-time var and his >>> metadata? I'm discovering functions like cljs.core/resolve-var but >>> doing (cljs.core/resolve-var &env v) in the macro from my original >>> example doesn't seems to resolve anything. >>> >>> I think for my real case there is a workaround by defining a (def >>> my-metadata-for-cljs-vars (atom {})) in macros.clj and then update it >>> in the mydefmulti calls using the fully qualified var sym as a key and >>> the data (originally stored in the metadata) as the value, then read it >>> from the mydefmacro calls. I think that will work, but I really want to >>> know if resolving the CLJS var and getting his metadata from the macro is >>> possible. >>> >>> >>> Saludos, >>> Nahuel Greco. >>> >>> >>> On Sat, May 31, 2014 at 5:50 AM, Thomas Heller <[email protected]> >>> wrote: >>> >>>> Hey, >>>> >>>> not sure what you are trying to achieve, since the compiler should >>>> already warn you if a var is not found. Might not do so when nesting defs. >>>> def/defn are top level forms und should not be nested, especially no def in >>>> a defn. >>>> >>>> As for your question: the CLJS compiler supports vars in macros, but >>>> only on the clojure side (eg. in your macros.clj). Your macros may >>>> reference other vars from the CLJ world but know nothing about the CLJS >>>> world (expect maybe from &env). >>>> >>>> HTH, >>>> /thomas >>>> >>>> -- >>>> Note that posts from new members are moderated - please be patient with >>>> your first post. >>>> --- >>>> You received this message because you are subscribed to the Google >>>> Groups "ClojureScript" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To post to this group, send email to [email protected]. >>>> Visit this group at http://groups.google.com/group/clojurescript. >>>> >>> >>> -- >>> Note that posts from new members are moderated - please be patient with >>> your first post. >>> --- >>> You received this message because you are subscribed to the Google >>> Groups "ClojureScript" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> To post to this group, send email to [email protected]. >>> Visit this group at http://groups.google.com/group/clojurescript. >>> >> >> > -- > Note that posts from new members are moderated - please be patient with > your first post. > --- > You received this message because you are subscribed to the Google Groups > "ClojureScript" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/clojurescript. > -- Note that posts from new members are moderated - please be patient with your first post. --- You received this message because you are subscribed to the Google Groups "ClojureScript" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/clojurescript.
