Re: Possible namespace bug

2010-05-25 Thread Meikel Brandmeyer
Hi, On May 26, 8:35 am, Brent Millare wrote: > Ah wait, I may have read that wrong. So what I understand is because I > am calling it from the the -e, it is ran in the user ns. Ok that makes > sense. Exactly! And in the Repl you are still in the bar namespace. Doing a (in-ns 'user) and then cal

Re: Possible namespace bug

2010-05-25 Thread Brent Millare
Ah wait, I may have read that wrong. So what I understand is because I am calling it from the the -e, it is ran in the user ns. Ok that makes sense. On May 26, 2:28 am, Brent Millare wrote: > Hi Meikel, > > Well if #'user/x is the correct behavior, then the repl behavior needs > to be fixed. Eith

Re: Possible namespace bug

2010-05-25 Thread Brent Millare
Hi Meikel, Well if #'user/x is the correct behavior, then the repl behavior needs to be fixed. Either one may be "correct" but that does not explain the discrepancy. Also I agree that eval should be avoided, but I found an extreme case where it was necessary (due to the desired side effect of star

Re: Possible namespace bug

2010-05-25 Thread Meikel Brandmeyer
Hi, On May 26, 12:17 am, Brent Millare wrote: > ^^ That should read #'bar/x instead of #'user/x No. foo/f expands into a macro calling eval on a def. This eval is put into a function bar/b. When you call the function the namespace "in charge" is user. So everything is correct. Usual disclaimer

Possible namespace bug

2010-05-25 Thread Brent Millare
May have found a bug, here is how to duplicate it. Hopefully someone can confirm this. Here is expected behavior when run in the repl: Clojure 1.2.0-master-SNAPSHOT user=> (ns foo) nil foo=> (defmacro f [] `(eval `(def ~'~'x 'foo))) #'foo/f foo=> (ns bar) nil bar=> (defn b [] (foo/f)) #'bar/b ba