The next feature I want to implement is "references". That is, one
selects a symbol, and then can go to the location where that symbol was
defined (e.g. def, defn, let, etc.). One can also get a list of all the
locations where that symbol is referenced. This feature is very nice
for navigating code, and is also the core of many automatic refactorings
Implementing references are pretty straightforward in a static language
like Java, were all the references are resolved at compile time.
However, in a language like Clojure some references get resolved at run
How do other IDEs handle this? Is there a recommended set of rules for
what references can and can not be resolved by the editor? How does one
detect a possible non-static reference, or how does one ensure that a
reference will always refer to the same location?
Note that I need a 100% reliable solution, if I am going to implement
automatic refactoring on top of it. No one wants refactoring that
messes up the code 5% of the time.
> Actually, the observation below might be really good news. Does it
> means that all references are resolved at compile time? Do I ever
> to run the code to figure out the context of a reference? Or, does
> lexical context give me all the information I need?
My understanding is that all references are resolved at compile time.
It's one of the design choices that helps make Clojure fast.
How is the Clojure compiler tested? Is there a set Clojure code that
serves as Unit tests? I need something with all the corner cases both
for syntax and references.
Am 17.01.2009 um 16:22 schrieb Peter Wolf:
> I think much of the parser, such as the JFlex lexer is certainly
> reusable. The recursive descent parser outputs Intellij objects, but
> with pretty minor changes could be made reuseable.
> Please feel free to take anything you want.
There is lots of such things going at the moment.
- the IntelliJ Plugin
- the swank/SLIME/emacs thingy
- my Vim Gorilla
Is there some interest to bundle the efforts?
I'm thinking about a project, which provides such common
things, like the Parser mentioned above. Or Chouser's or
cgrand's javadoc. Everything in a neutral way, so that the
specific frontend projects just provide the interface to the
IDE in question and use the same backend functions.
This would allow a faster development for the different
platforms, since re-inventing the wheel is not necessary.
I don't know the requirements of the different platforms,
let alone how to implement all the features like refactoring
and stuff. So I don't even know, whether this is possible
So what do you think?
Am 17.01.2009 um 18:12 schrieb Meikel Brandmeyer:
> things, like the Parser mentioned above. Or Chouser's or
I'm sorry. I meant Chouser's show.
As a first cut, I think we need to separate those tools written in JVM
languages (Clojure/Java) and those written in something else.
I certainly think the JVM based projects can, and should, share
components. BTW the most important JVM project is Clojure itself. The
tools should share as much as possible with the Clojure core sources.
Tools such as SLIME and (I think) Gorilla, on the other hand, are not
written in language that makes sharing easy.
However, I would be very much in favor of a common test set. A
collection of Clojure code that can be used to test tools, and ensure
common behavior. These would be useful for all tools written in all
My 2 cents
Am 17.01.2009 um 20:03 schrieb Matt Revelle:
>> Tools such as SLIME and (I think) Gorilla, on the other hand, are not
>> written in language that makes sharing easy.
> This is not entirely correct. SLIME works by communicating with the
> running Lisp process (in this case, Clojure), essentially all the
> integration between Emacs/SLIME and Clojure is written in Clojure.
> The component of SLIME that runs in the Lisp process is called SWANK.
Yes. Gorilla also consists basically of some part on the Vim side,
which sends stuff to a Clojure server. That part is written in Clojure.
The result is sent back to Vim.
So stuff like function completion etc. can be easily shared.
Am 17.01.2009 um 21:16 schrieb Stuart Sierra:
> SLIME communicates with SWANK via a well-defined
> socket interface, see <http://common-lisp.net/project/slime/>
Hmm.. I looked there before, but I couldn't find a definition
of the interface protocol.
> swank-clojure could be a place to implement shared-backend features.
> Then again, you might not even need to modify swank-clojure. Since
> SWANK can send arbitrary expressions to the Clojure process, you could
> implement your introspection/reflection/refactoring features in pure
> Clojure (like show, source, javadoc) and just call them through SWANK.
Unfortunately, I can't use swank due to the restrictions
imposed by the GPL.
Am 17.01.2009 um 21:40 schrieb lpetit:
> Now that's interesting. It may be easier to share code because you too
> decided to not follow slime/swank which, I guess, imposes as a middle
> language something closer to emacs-lisp than to clojure for the
> exchanged data structures.
Well. I'm not sure I understand you correctly. The current layout
is as follows:
A Ruby interface in Vim, which extracts data etc. and sends
via the Ruby telnet client simple clojure expressions to some
There a Clojure server listens and simply executes the expressions
in Repl and sends back the result.
There is no real protocol defined at the moment and I'm somewhat
limited with the results, since implementing parser in Vim is no
fun.... But this simple setup already allows gems like a remote
clojure server or a Repl in a Vim buffer.
At the moment I'm investigating nailgun to eliminate the Ruby
> And we could indeed also share the whole code of the server side.
That would be a tremendous win. I think interfacing to the IDE/editor
is already quite some work.
> I'm in the process of refactoring the code (client and server) for
> We have currently one single function, that returns a big map with all
> the information for the namespace.
> This has allowed me to do a namespace browser for clojuredev :
Uh. Nice. I'll give that a try. Let's see whether I can interface
On Sat, Jan 17, 2009 at 12:47 PM, Meikel Brandmeyer <m...@kotka.de> wrote:
> Hi Stuart,
> Am 17.01.2009 um 21:16 schrieb Stuart Sierra:
>> SLIME communicates with SWANK via a well-defined
>> socket interface, see <http://common-lisp.net/project/slime/>
> Hmm.. I looked there before, but I couldn't find a definition
> of the interface protocol.
To better understand the SLIME/SWANK communications protocol, you can:
1. Read the source code (search for "Communication protocol" in
slime.el and read the code from that point)
2. Look at Tobias Rittweiler's excellent SLIME presentation
3. Examine the contents of the *slime-events* buffer in Emacs (it
contains the actual exchanges between the SLIME/SWANK components)
My recent SLIME blog post has a lot of links to other material that
you might find useful: http://bc.tech.coop/blog/081209.html