My favorites | Sign in
Project Home Downloads Wiki Issues Source
New issue   Search
  Advanced search   Search tips   Subscriptions
Issue 443: clojure.repl naming clashes
2 people starred this issue and may be notified of changes. Back to list
Status:  WontFix
Closed:  Oct 2012

Sign in to add a comment
Reported by, Sep 28, 2012
What steps will reproduce the problem?

Open any Clojure file, add a 'source' var:

(def source)

Switch REPL to file's namespace (Alt+Cmd+N), then load file in REPL (Alt+Cmd+L).

What is the expected output? What do you see instead?

Expected clean compilation. Got an exception:

CompilerException java.lang.IllegalStateException: source already refers to: #'clojure.repl/source in namespace: XXX.YYY, compiling:(XXX/YYY.clj:ZZZ)  

What version of the product are you using? On what operating system?


Please provide any additional information below.

This only happens when the REPL is in the same namespace as the file. I assume it's the auto-aliasing of the clojure.repl functions - the same exception is thrown with a var named 'doc', 'dir', etc.

Oct 1, 2012
Project Member #1
Chas, maybe you can give some highlight ?
I supposed that repl auto-aliasing were also set on the 'user namespace, but I am potentially wrong ?

Isn't this auto-aliasing dangerous, e.g. you want to just "inspect" some part of an app in production, you happen to load for the first time one of your app's namespace, and if it contains a var named source, this could cause problems?
Oct 1, 2012
Project Member #2
This is an nREPL bug, and a sneaky one at that.  I've created an issue:

I'd love to hear a smarter solution.
Status: Accepted
Oct 2, 2012
Project Member #3
If I understand things right, the problem lies in these 3 lines:
, because they execute in the context of the target namespace. This is indeed highly undesirable, but now that several Clojure versions have been released with this code, we're screwed, aren't we?

Could there be a possibility to trick the repl function by set!ing *ns* to 'user namespace during this "init" phase, and set!ing it back to the right namespace as a first action (need to encapsulate inside a (do ....) again, bleh) ... ?

Anyway ... there seem to be a lot of things that are of no use in main/repl , so why not just roll your own? Would it break e.g. reply?

Oct 2, 2012
Project Member #4
I'm sure some trickery could be found, but further tying nrepl to that fn seems like a bad idea.  Replacing it with its own impl won't break anything, but that *does* mean that future changes to clojure.main/repl won't propagate into nREPL automatically.
Oct 2, 2012
Project Member #5
Do you see any value in trying to "fix" main.repl (maybe separating into several parts, etc.), so that it could e.g. be part of clojure 1.5 ?

Then based on Clojure version, you could use nrepl's own impl or enhanced main.repl, which could eventually lead to removing nrepl's own impl?
Oct 2, 2012
Project Member #6
I'll send a message to clojure-dev with the idea, although the implicit refers were added as an enhancement; we'd need to come up with a way to maintain those refers within 'user.

In general, it's not *bad* to use one's own core repl fn; presumably, there's little that will change over time in this area.
Oct 2, 2012
Project Member #7
I'm all for own repl fn. 
Oct 10, 2012
Project Member #8
(No comment was entered for this change.)
Labels: nnext
Oct 22, 2012
Project Member #9
I managed to get a "fix" for clojure.main/repl into Clojure (though it's really a nice improvement w.r.t. settling how default refers happen in general), and that'll be in place for the 1.5.0 release(s).  See and for details on the change.

This unfortunately means that anyone using Clojure < 1.4.0 will continue to be affected by the problem described here.  But, that's something I can live with at this point.

Laurent, I leave this to you, since there's nothing to be done with ccw here.
Oct 23, 2012
Project Member #10
Chas, I agree that if this is fixed in 1.5, then we're probably ok no to try some dark magic to make it work <= 1.5.

So I'm marking it as WontFix.
Status: WontFix
Labels: -nnext
Sign in to add a comment

Powered by Google Project Hosting