Hello Rich, 2009/3/17 Rich Hickey <richhic...@gmail.com>
> I remain opposed, and here are some more reasons: > > when you say > > (def foo [x] > (bar x 42)) > > you are as likely to be referring to a forgot-to-require bar-lib as > you are to a to-be-defined bar. > > The compiler can only default the latter, by interning bar in the > current namespace. There is no notion of compiling with a placeholder, > the name must be resolved to something. Should you really intend the > former, you end up with a mess, as you add (:require bar-lib) to your > ns call only to have it fail with a conflict - bar already defined in > your-ns. > > Then you have to ns-unmap bar and retry. This is a big pain and one > you encounter all the time in Common Lisp, where the reader has auto- > interning characteristics similar to what is being discussed here. Well, I dedicated some time on this, as a general exercise to understand a little bit more clojure internals, and as a specific exercise on the topic. I was trying to implement something a little bit more interesting than what you are describing above : given a "unit of compilation", every "missing symbol" is added to a list specific to the current unit of compilation, and at the end of the unit of compilation : either all symbols have finally been resolved, either at least one did not => and then the unit of compilation automatically unmaps all symbols in the list - leaving the namespace clean. What do I call a unit of compilation ? the limits of a unit of compilation are easy to spot I -maybe too naively ? - think : "top level" call to eval, compile, or one of the "load" flavors. Anything based on a unit-of-compilation concept has real problems for > Clojure, which generally treats a program as a stream of expressions. I guess it's currently not totally true, given e.g. that load, ... install bindings for a substream of the expressions it manages ? (But maybe I'm wrong here, please excuse me if this does not make sense - just trying to understand) Looking ahead is not an option, especially at the repl and other > streaming scenarios. > > The biggest reason is - I'm not having the problems you are > describing, and neither are other experienced Clojure developers - > many of whom use the repl a lot. Well, this above other things is indeed sufficient to place priority on other functionalities ;-) Regards, -- Laurent --~--~---------~--~----~------------~-------~--~----~ 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 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 -~----------~----~----~----~------~----~------~--~---
