*ns* is bound at execution time, not at compile time. Eval here postpones the definition at runtime after the bindings have been evaluated and *ns* gets rebinded.
Otherwise the definition would be created at compile time in the namespace of the caller. The full form has to be compiled to get the new bindings evaled. Leaving def unwrapped would get it done at compilation time, not at runtime. Is this a bit clearer ? Luc P. > > On Thursday, May 29, 2014 8:43:58 PM UTC-7, squeegee wrote: > > > > > > On May 29, 2014, at 7:11 PM, ian.tegebo <ian.t...@gmail.com <javascript:>> > > wrote: > > > > user> (binding [*ns* (the-ns 'blah)] (defn foo [])) > > #'user/foo > > user> (binding [*ns* (the-ns 'blah)] (eval '(defn foo []))) > > #'blah/foo > > > > In the first case, the defn form is compiled before the binding to (the-ns > > ‘blah) is in effect. > > > > It's exactly this point that's confusing. > > The defn form expands into a def, whose documentation says it uses the > current namespace. The current namespace, as I understand it, is what's > bound to *ns* which IIUC should have been accomplished with the "binding" > macro. The first code snippet was meant to demonstrate that. Here's > another variant in case there's confusing about *ns* being lexical: > > user> (defn println-ns [] *ns*) > #'user/println-ns > user> (binding [*ns* (the-ns 'blah)] (println-ns)) > #<Namespace blah> > > I don't see the reason why def should behave as it currently does; it seems > like it should lookup the current thread-binding for *ns*, making the > second case's use of eval unnecessary. Since it doesn't, I'd like to know > why it couldn't (or shouldn't) do the thing that seems more intuitive. > > That said, if the special form let* does not evaluate its arguments in left > to right order such that let* actually evaluates def's before anything > else, then I would understand why the current behavior is the way it is > However, then I'd just be curious about let*... > > > -- > 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 unsubscribe from this group and stop receiving emails from it, send an > email to clojure+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- Luc Prefontaine<lprefonta...@softaddicts.ca> sent by ibisMail! -- 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 unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
