[slime-devel] Re: giving reasons for RPC aborts

[Tobias C. Rittweiler]

Taylor R Campbell <campbell at mumble.net> writes:

> (I asked about this a year ago, but must have forgotten about it.)
>
> There are many cases where a user invoked a command that doesn't make
> any sense, so the RPC can't complete with a meaningful answer, but it
> would also be overkill to throw the user into a debugger.  It would be
> nice to abort the RPC with a message to the user, such as `Package
> does not exist' for `slime-repl-set-package' or `Undefined function'
> for `slime-disassemble-symbol'. 

The nice thing about the current behaviour is that it's (perhabs
arguably) convenient if the host Lisp provides appropriate continuation
restarts.


> It looks like there was once a time when a message could be supplied
> with a :ABORT result from an RPC, and there are some vestigial
> remnants of support for it -- `slime-rex' forms with (:ABORT &OPTIONAL
> REASON), and indeed the documentation of `slime-rex' says that the
> reason is not optinoal --, but there are many other uses that prohibit
> a reason from being supplied.
>
> Is there a good reason for :ABORT responses not to have an optional
> message associated with them, or would a patch be welcomed for all of
> the uses of `slime-rex' to consistently accept an optional message?

I have done some work to take these messages into account at the REPL
(cf. entry 2007-05-14) -- however, the problem is not so much with
"accepting messages from Slime", but that not much code in SWANK
appropriately calls SWANK:ABORT-REQUEST (and maybe rightly so!)

For instance, take the following into consideration:

  CL-USER> (swank::decode-keyword-arg '#(1 2 3))
  ; Evaluation aborted: Bad keyword item of formal argument list

  CL-USER> (swank::decode-keyword-arg '(#(1 2 3)))
  ; ==> thrown into debugger with 
  ;
  ;        The value #(1 2 3) is not of type SYMBOL.
  ;        [Condition of type TYPE-ERROR]

The difference is that the first case is explicitly handled with an
invokation of ABORT-REQUEST. Similiarly to make the cases you mentioned
above actually return a message, the respective functions of SWANK would
have to be modified to test for bad data, and invoke ABORT-REQUEST
accordingly.

That is not to say that I'm against your proposed changes to slime.el.
(And of course, I can figure that you probably want that for SLIME48, so
the SWANK side is not as much of a matter for you.)

  -T.