[slime-devel] Re: SWANK and *read-eval*

[Matthias Koeppe]

"Tobias C. Rittweiler" <tcr at freebits.de> writes:

> Matthias Koeppe <mkoeppe+slime at mail.math.uni-magdeburg.de> writes:
>
>> The solution in the new version of READ-FORM-SPEC is not sufficient,
>> because it does not handle symbols interned in nested forms.
>> [(defmethod (tyy zzz) abcd ...]
>
> Yeah, that was a bug.
>
>> In general the "destroy-and-repair" (here: "intern-and-unintern")
>> method is not giving a clean implementation.
>
> I agree that it's not very clean. But it seems to be an acceptable
> tradeoff to me:

I do not agree, see below.

> The code now only hard-interns on very obscure occasions (or so I
> hope!), and should not do so any more than of before my changes on
> the same instances.

My old code worked perfectly, it never interned anything on autodoc.

This is an essential, non-negotiable requirement, as it is invoked
automatically, on pretty arbitrary stuff from buffers that is gathered
by some heuristic on the Emacs side.

I do not accept replacing this by something that works "most of the time".

You simply cannot control the interning behavior of READ.  Look what
happens when a reader error occurs somewhere.  You have no control
over what symbols it has already interned when the error is signalled.

I type:

  (defmethod (foo #Q) 

Now:

(find-symbol "FOO")
FOO
:INTERNAL

> And the code does actually deal with `C-c C-s' -- which, as I
> mentioned already, interned everything previously.

If we can achieve that, it would be great; but C-c C-s is explicitly
user-invoked, so interning safety is not essential.

> And I personally use C-c C-s much more often than stumbling over one
> of those obscure occasions.

The problem is one cannot know when the obscure occasions occur.

>> What you need to do -- if you want to use your proposed protocol of
>> sending forms to SWANK -- is implement a limited reader in
>
> (I'm open for suggestions to improve the protocol. I just tried to keep
> it as simple and as flexible as possible.)

I designed the old protocol (which just gathers the required
information for every supported operator in a safe way) specifically
to avoid READ.  You either implement something like this again, or as
an alternative you employ a safe restricted reader.

>> READ-FORM-SPEC.  It only needs to handle lists, numbers, strings, and
>> symbols to be useful in this context.  It should never intern symbols
>> and gracefully handle what would be a reader error for READ.  It
>> should not be very hard to write; give it a try.
>
> I've thought about that before, but how is this supposed to work with
> `slime-complete-form' without reimplementing a whole reader?

You use the safe reader for autodoc, where safety is essential.

For slime-complete-form, you offer two modes, controlled by a user
variable.  One safe variant that cannot handle everything.  One
less-safe variant (using READ) that can handle everything.

> There's currently a bug I've tried the whole day to track down,

Sorry, I don't have time to work on it.  Check whether the cache works
and whether there are equality issues.

Matthias
-- 
Matthias Köppe -- http://www.math.uni-magdeburg.de/~mkoeppe
(currently @math.ucdavis.edu)