2011/3/21 blais <martin.bl...@gmail.com> > 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? >
Because it seems to be opiniotatedly undocumented, for one. Everytime I tried to get info, the final answer was something like "reverse engineer the protocol". No, thank you. > 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 > -- 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
