[slime-devel] broken clojure REPL

[Terje Norderhaug]

On Jan 9, 2010, at 7:23 AM, Steven E. Harris wrote:
> "Tobias C. Rittweiler" <tcr at freebits.de> writes:
>
>> The point is that you're not trying to use a Lisp reader to read what
>> looks very much like Lisp forms, but you're trying to use the Clojure
>> reader. And the Clojure reader is very restrictive in what it accepts
>> as symbols.
>
> Well, I wrote "Lisp" as opposed to "Common Lisp" to generalize the
> complaint. One can imagine SLIME having originated for some Lisp that
> allowed symbols like ":::foo", which the Common Lisp reader would not
> read without complaint. Are we not biased in this debate due to SLIME
> having been made for Common Lisp?

Even the Common Lisp reader will barf when encountering symbols that  
are in an non-existent package, like those passed through the swank  
protocol from another lisp system. We had to work around that for the  
MCLIDE client, which is implemented in Common Lisp.

>> The easiest compromise is to change %CURSOR-MARKER% to +CURSOR- 
>> MARKER+
>> which, if I read the documentation right, the Clojure reader will
>> accept. Doing so, is sweeping a problem under the carpet.
>
> Yes, I agree, insofar as either protocol participant is using a parser
> (be it the Common Lisp, Clojure, or ELisp reader) that isn't just
> reading a string.
>
> However, to recommend that the protocol participants implement a  
> parser
> from scratch to read these Lisp forms seems unreasonable too; after  
> all,
> the protocol looks to have been designed for writing and reading Lisp
> forms directly. It can't just be an accident that there are paired
> parentheses and keyword-style tags.

A problem is that the swank protocol allows the full common Lisp  
syntax, with a few self-imposed limitations to make the output  
compatible with emacs lisp. The consequence is that it is a  
substantial job to implement a custom reader.

>> I still think that it is Clojure that should "change". It should
>> provide a way to READ in a form with minimal processing -- something
>> that CL's reader, for instance, does not really allow to unfortunate
>> consequences.
>
> Does using the protocol require a parser separate from a
> lowest-common-denominator Lisp reader? If so, would you introduce  
> syntax
> that the Common Lisp reader couldn't accept?

Now that there are multiple clients and servers, I think it is time  
that we formalize the lisp syntax of the messages in the swank  
protocol. It should be simple, limited to a subset of what is allowed  
by Common Lisp... something parseable with say less than a page of  
lisp code.

Swank clients and servers should adhere to this syntax in the  
messages they produce, but should not be required to implement a  
validating parser for reading. Implementations may continue to use  
the lisp reader as before, although writing a custom reader would be  
trivial with a well defined and simple message syntax.

-- Terje Norderhaug
   terje at in-progress.com