On Mar 20, 2011, at 10:48 PM, blais wrote: > On Mar 20, 12:16 pm, Chas Emerick <cemer...@snowtide.com> wrote: >> Martin, >> >> Thank you for the pushback. :-) > > I'm not pushing back, I'm really just trying to understand...
In any case, I appreciate public thrashing of design and implementation choices (as long as the process is productive). >> On Mar 19, 2011, at 8:30 PM, Martin Blais wrote: >>> I think this is wrong, because every single IDE client >>> will have to adapt itself to the various changes occurring >>> in the Clojure VM as it evolves. This is just creating M >>> times the amount of porting problems (for each client). By >>> keeping the complexity on the server, every IDE that >>> speaks a common protocol (*) works between versions. >> >> There's no reason why the server couldn't provide a standard set of >> introspection / tooling utilities available -- it would be as easy >> as adding a proper dependency e.g. in your web project's >> pom/project.clj. > > Then you'd just be redoing Swank all over again. You'd be redesigning > a different protocol to support the same kinds of operations. I don't > really see the point, unless the current protocol is unsuitable > somehow. The operations that would be provided by a tooling library would have zero impact on the nREPL protocol. There's no reason why a particular client would have to either (a) use the server's provided set of tooling functions or (b) use any particular standard set of tooling functions. It's just code that's being loaded somewhere, and then called later on -- no protocol changes. >> Because a synchronous client is unsuitable for REPL tasks that >> require or desire asynchronous evaluation of expressions. > > I think you're missing my point; I understand that request/response is > necessary for rich interaction and I understand why. What I'm saying > above is that a dead simple option with no async support is also > really valuable, because it is unlikely to break between versions, and > it's already good enough for a lot of users via stdin/stdout pipes > (i.e., inferior lisp). I agree. A project that would open up REPL streams over telnet would probably be very simple, and worth doing. It's just not suitable for the cases that nREPL is aimed at. >>> IMHO if people will bother implementing a request/response >>> protocol, why not just stick with a rich protocol like >>> Swank's? It'll just be reinventing the wheel otherwise. >> >> Swank is fundamentally emacs-only, and is defined outside of the >> Clojure community. I discuss the issues with swank in the readme >> here:https://github.com/clojure/tools.nrepl > > You don't. I have read both the nREPL readme and the document you link > to; they state that swank is unsuitable somehow, but it doesn't say > why. > > Why is swank an unsuitable protocol? > What are its shortcomings? > What features that it doesn't support require redesigning another > protocol? > > (Keep in mind: Swank != Emacs.) Really? I recall reading this a while ago when I was originally investigating swank: > If you are not someone who likes to read documentation, you can avoid 99% of > the problems that people have with SLIME by following one simple rule: > Always use the latest CVS version of SLIME with the latest development > version of the Lisp implementation. > Due to the "symbiotic" relationship between SLIME and SWANK, it is not > uncommon for changes (in either SLIME or the underlying Lisp) to "break" > things. AFAICT, this hasn't changed. Swank is the backend part of SLIME, not anything like a standard for lisp connectivity. I don't want my tooling to break when someone changes swank upstream to add a feature or fix a bug in e.g. CMUCL, and I'm pretty sure that users of e.g. ccw or vimclojure don't want to have things go south when something changes in the emacs world. In any case, the protocol itself is besides the point. As Laurent said elsewhere in this thread, swank seems to be opinionatedly undocumented. My best understanding of it comes from the swank-clojure project, and from there I get the impression that swank: assumes an emacs client assumes a SLIME client assumes a Common Lisp, or at least CL idioms defines a fixed set of tooling-related operations (many of which are simply not germane – e.g. restarts and such – while it's not clear how one would support other tooling operations that might be useful given the JVM host) includes its own authentication mechanism (ack!) So, my biggest technical objections to swank have nothing to do with it's protocol necessarily, but its apparent semantics and assumed usage. >> Again, the nREPL readme goes into the motivation for discounting >> swank. As far as I can tell, its big advantage is that it is what >> SLIME uses. > > It does not. There is no detail that describes what functionality is > already available in Swank, how it fails to reach the desired goals of > a client/server connection to Clojure, and what those goals should be, > and why simply extending Swank would not work. The nREPL readme is not the place to document swank, even if I were to want to take up such a challenge. FWIW, I did consult with some people that have significant knowledge of swank; their impression of it helped confirm my initial concerns. > I also fail to see how Clojure's differences with other LISPs, however > fundamental, require anything else that Slime already provides or that > could be added with only minor changes. AFAIK minor additions to Swank > could be added--it's open source, and other clients could speak Swank > as well. > > Remember: Swank != Emacs. > Swank just transfers LISP data. Just saying that something is open source and that other clients could be made compatible with it doesn't make it so. Swank has nontrivial semantics that do appear to be bound up with SLIME and emacs, and is fundamentally intended for use with Common Lisps. Besides the technical challenges, swank is not a stable project managed separate from its primary client (SLIME). When I see admonitions from a years-old project to always use HEAD from CVS, I assume it's not something I want to build on top of. Pushing around lisp forms makes things easy if there's a lisp on both sides of the connection, but is an active impediment otherwise. What if someone wants to connect to a Clojure VM from Java or Ruby or Bash or VB.NET? >> If you were to consider what a dedicated Clojure toolchain for >> emacs would look like, I'd be very surprised if it involved swank. > > So, what features not supported in Swank would be supported? Nothing about this discussion has been about particular features; no one is saying swank is unacceptable because it doesn't support feature-X out of the box. On the other hand, I'm certain that if Clojure developers and tools need some feature or change from nREPL, it will absolutely happen, it will be implemented in Clojure, and it will work well across all versions of Clojure that nREPL supports at the time. Even if someone were to build a Clojure swank client, I can't see how the same dynamic would apply. After going through the above, I think it's worth asking: what about swank is so great that it should wag the dog here? - Chas -- 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
