About the namespace problem: I do a <i>lot</i> of refactoring, and namespaces were never my problem, because the types of errors op is talking about could be handled by the test suite, and/or cider reloading. I really think I would <i>not</i> want versioning of my namespaces - that would make a huge mess. So like many other ideas that sound good and pure and elegant at the first glance, I think this one would be an overly complex mess in practice.<p>BUT, there is a more important thing, and there I support the author: instead on pushing Rich (the author of Clojure) to include any shiny feature that someone thinks would be nice, and then complaining that Rich ignores the request, the OP forked Clojure and tries to prove that his ideas are better. I think Rich does quite well on keeping Clojure sane and useful. I have no doubt that he will include stuff that really proves to be better. But, 99% of stuff is better only while is on scratchpad, but turns out either irrelevant, or, even worse, outright horrible in practice.<p>That's why I think that everything that can be a library should be a library instead a part of clojure.core. Those things that could not be libraries (not many of those come to my mind) should first be proven in some sort of "experimental" clojure. clojure.core should stay as it is :)
TL;DR: forking Clojure to fix namespaces.<p>> Because namespaces are mutable, even if I were to perform a rename correctly, the old name is still present in the namespace.<p>First, ns-unmap your old name (a refactoring tool should do that for your, I guess). (edit: Clojure is a Lisp-1).<p>> What if we gave Namespaces and Vars version numbers? When a Namespace is re-defined (the ns form is evaluated) then the Namespace's version is incremented. When a def is evaluated, the version of the Var bound by the def is set to be the version of the Namespace in which that Var exists.<p>Your environment could keep track of definitions and usages of your symbols (see for example slime-who-calls, etc.). That would be a good improvement for Clojure.<p>There is another problem: define namespace N, define variable N/x, using it in another namespace M, remove namspace N. Then, an old name x is referenced from M which does not exist in any namespace. Also, you redefine namespace N with a new x, and now old-x and new-x are different objects. I don't think version numbers would help you here.<p>I am just thinking aloud, but when remove-ns is called, you could re-parent orphaned names from that package to a global "orphans" table. When you intern a symbol in a namespace, first you try to see if you can recycle objects from "oprhans" based on their fully qualified name. So that new-x and old-x are in fact the same name object.
Or, you just use a global map to store fully qualified names in the first place. Maybe the metadata attached to orphaned symbols should be cleared in this approach, to avoid keeping irrelevant data about a name when it is reused.<p>But again, you should be careful when you rename namespaces. Maybe the best answer is to simply be aware of the possible pitfalls.
Good initiative.<p>Clojure developement is driven by the needs of Rich/Datomic these days, it's understandable this might be frustating for users who wish clojure was more community driven, and exploring other areas.<p>I personally gave up on it because of this (I used to do clojure full time).
On the topic of forking Clojure, I've had sort of an interest in writing a pure C version of the core of Clojure for a while; something with similar goals to Lua, namely that it would be self-sufficient, portable, and embeddable; a library first, much like Clojure is in Java. I guess it should be called Clocure if it ever came into existence. But honestly, I have no personal need for this, it's only something I like the idea of, and therefore I don't ever see myself actually writing it. (I guess I might use it for some small-ish scripts that I might otherwise go to Python or Ruby for. But I hardly write such small scripts anymore.) Either way, I still like the idea and will probably continue dreaming about it for a while to come.<p>That said, I have to second the other opinions in this thread, namely, that Jaunt is solving a problem in Clojure that already has other solutions. When I'm writing Clojure for work (I use it full time), I use Cider, and I often make use of C-c u, which is cider-unset, allowing me to make sure I remove a var from a namespace. That plus cider-reload gives me assurance that my namespace mutations are pretty reliable.
Sounds like it fits within the "staged programming" model, which I think is a very interesting and relatively unexplored approach to adding some degree of dynamism into a statically typed language (which is not necessarily the goal here ...) It would be cool to have more of these systems reach the level where they are usable in commercial projects.