100% expected. Try (def other.ns/some-var 1) - the compiler tells you it's illegal. If you read the compiler source, it's looking at the var's namespace and refusing to def it if it's not the current namespace.
If you want behavior like this, you want (intern), not (def). On Aug 16, 12:07 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote: > I *think* it is expected behavior. Take this with a grain of salt, > but I *think* that defs are namespace resolved at compile time, and so > will not be checking in-ns calls within a function to determine the > appropriate namespace, but will instead always use the ns of the > function containing the def. > > - Mark > > On Tue, Aug 16, 2011 at 2:54 PM, Richard Rattigan <ratti...@gmail.com> wrote: > > > > > > > > > Thanks for your replies. Do you think this is a bug, given that the > > documentation doesn't seem to concur with this behaviour? > > > On Aug 15, 9:54 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote: > >> Wow, forget everything I said, this has nothing to do with macro > >> expansion. Looks more like inside a function you can only def > >> something in the same namespace as the function: > > >> user> (defn ff [] (in-ns 'foo.core2) (def anything5 10)) > >> #'user/ff > >> user> anything5 > > >> Var user/anything5 is unbound. > >> [Thrown class java.lang.IllegalStateException] > > >> user> (ff) > >> #'user/anything5 > >> foo.core2> (in-ns 'foo.core2) > >> #<Namespace foo.core2> > >> foo.core2> (def anything6 10) > >> #'foo.core2/anything6 > > >> On Mon, Aug 15, 2011 at 9:36 PM, Mark Rathwell <mark.rathw...@gmail.com> > >> wrote: > >> > You are correct, I must have messed something up in my expansions. > >> > From the below, however, it looks like a var is being declared just by > >> > having the macro called, but not bound to the value: > > >> > user> (defmacro foo [name & body] `(def ~name ~(identity `(fn [] > >> > ~@body)))) > >> > #'user/foo > >> > user> (foo xx (in-ns 'foo.core) (def anything3 10)) > >> > #'user/xx > >> > user> anything3 > > >> > Var user/anything3 is unbound. > >> > [Thrown class java.lang.IllegalStateException] > > >> > user> anything4 > > >> > Unable to resolve symbol: anything4 in this context > >> > [Thrown class java.lang.Exception] > > >> > On Mon, Aug 15, 2011 at 8:56 PM, Alan Malloy <a...@malloys.org> wrote: > >> >> I either disagree or don't understand. The deftest macro doesn't touch > >> >> your &body arg; it's expanded as-is. For example, (let [x 'foo] `(inc > >> >> ~x)) doesn't result in foo getting qualified, and most macros behave > >> >> the same way. > > >> >> On Aug 15, 4:36 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote: > >> >>> Just to be clear, it is namespace resolved because of syntax quote: > > >> >>> (defmacro deftest > >> >>> [name & body] > >> >>> (when *load-tests* > >> >>> `(def ~(vary-meta name assoc :test `(fn [] ~@body)) > >> >>> (fn [] (test-var (var ~name)))))) > > >> >>> On Mon, Aug 15, 2011 at 7:23 PM, Alan Malloy <a...@malloys.org> wrote: > >> >>> > Is it? That's neat; I guess I've never thought about how the compiler > >> >>> > treats def. Thanks for the explanation. > > >> >>> > On Aug 15, 3:03 pm, Mark Rathwell <mark.rathw...@gmail.com> wrote: > >> >>> >> deftest is a macro. Macros are expanded at compile time. So, in > >> >>> >> this > >> >>> >> case, at compile time, a function called namespace2 is def'd with > >> >>> >> meta > >> >>> >> data :test set to the body of your deftest. > > >> >>> >> All of that body is namespace resolved in macro expansion, before > >> >>> >> in-ns is ever executed (which happens when you actually call the > >> >>> >> namespace2 function created by the macro). Put another way, (def > >> >>> >> anything 10) is namespace resolved to (def > >> >>> >> learn.clojure.test.core/anything 10) at macro expansion time > >> >>> >> (compile > >> >>> >> time), before the test function is ever called, and thereby before > >> >>> >> in-ns is ever executed. > > >> >>> >> Hope this helps. > >> >>> >> On Mon, Aug 15, 2011 at 5:07 PM, Richard Rattigan > >> >>> >> <ratti...@gmail.com> wrote: > > >> >>> >> > I'm finding that namespaces don't seem to behave as I expect > >> >>> >> > intuitively, or according to the reference. It's quite possible > >> >>> >> > I'm in > >> >>> >> > the wrong here though, as I'm just kicking clojure's tires at this > >> >>> >> > point. > > >> >>> >> > Here is the relevant doc: > > >> >>> >> >http://clojure.org/special_forms > >> >>> >> > (def symbol init?) > >> >>> >> > Creates and interns or locates a global var with the name of > >> >>> >> > symbol > >> >>> >> > and a namespace of the value of the current namespace (*ns*). > > >> >>> >> > In the test below, which succeeds, the var does not appear to end > >> >>> >> > up > >> >>> >> > in the "current namespace" per this definition. Am I > >> >>> >> > misinterpreting > >> >>> >> > something, or is this a deviation from the spec/reference? > > >> >>> >> > (ns learn.clojure.test.core > >> >>> >> > (:use [clojure.test])) > >> >>> >> > (deftest namespace2 > >> >>> >> > (in-ns 'my.new.namespace) > >> >>> >> > ;confirm the current namespace > >> >>> >> > (is (= "my.new.namespace" (str *ns*))) > >> >>> >> > ;attempt to def a var in the current namespace > >> >>> >> > (def anything 10) > >> >>> >> > ;the var is not defined in the current namespace > >> >>> >> > (is (nil? (ns-resolve *ns* 'anything))) > >> >>> >> > ;the var is however definined in the orginal namespace > >> >>> >> > (is (not (nil? (ns-resolve (find-ns 'learn.clojure.test.core) > >> >>> >> > 'anything)))) > >> >>> >> > (is (= 10 learn.clojure.test.core/anything))) > > >> >>> > -- > >> >>> > 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 > > >> >> -- > >> >> 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 > > > -- > > 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 -- 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
