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... > 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. > A few people have been discussing the desired capabilities, and > have started documenting desired semantics, and where each > capability has already been implemented. Where is this information? > > - I take another issue at nREPL: if someone is going to > > implement a request/response protocol that supports only > > generic requests (because the complexity should live in > > the client), why bother at all, why not instead just make > > it a really, really simple network REPL, without any > > protocol at all? e.g. all input means "eval", output is > > just output, no ids no nothing.... just a socket that you > > could connect to with telnet and have a repl right there, > > no protocol. telnet localhost 4005, type "(+ 2 2)" at the > > terminal, see "4" appear. That's it. > > > I think it would be pretty straightforward to extend > > Emacs' inferior-lisp-mode to support talking to a socket > > like that instead of having to start a subprocess. This > > would give you "vanilla" communication with a live Clojure > > VM without having to start the VM from a parent process. I > > rather like this idea; it's the simplicity you currently > > enjoy with inferior-lisp, but over a socket; simple, can't > > break. > > 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). > > 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.) > > - Another problem with Slime that turns people off is the > > weirdness in where the output goes. To detail the > > weirdness: > > How SLIME works (or its problems) is entirely orthogonal to network REPL > design IMO. Sure; Note that fixing a couple of warts in Slime will make it good enough for a section of folks which may think that it's broken right now. The problem is not that Slime/Swank is broken, the problem is that it has a few warts that make it look radically different from a simple REPL with pipes, which I think is why some people dislike it. It probably just needs a bit more polishing. > nREPL breaks up *err*, *out*, and a printed representation of > expression results into separate slots in its responses, so clients > can display response data however is appropriate for their > environment. Note that I'm planning on adding optional multiplexing > of System/out and System/err (much like is done in Cake) to nREPL so > that clients can subscribe to those streams as desired. > > > (*) Please note: I am aware that only Emacs supports the > > Swank protocol right now but I don't see why other IDEs > > couldn't support it too--it's just made up of LISP forms > > after all; in other words, if someone wants to replace > > the swank protocol by an equivalent one with a different > > encoding I don't really see the point. Anyway, for this > > discussion I'll assume emacs-rex is a suitable enough > > protocol; in fact, I think it probably is, because it > > has already proved itself with a large number of LISP > > environments, it has "history". In any case, that's a > > separate discussion. I think of emacs-rex as just "the > > protocol" and that other IDEs could implement it to talk > > with swank-clojure. > > 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. 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. > 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? -- 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
