On Jan 9, 2010, at 7:23 AM, Steven E. Harris wrote:
"Tobias C. Rittweiler" tcr@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@in-progress.com