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

[Taylor R Campbell]

   Date: Fri, 29 Jun 2007 09:22:26 +0200
   From: "Tobias C. Rittweiler" <tcr at freebits.de>

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

Restarts do make it possible to work around these situations, but I'd
hardly call it `convenient'.  The situations to which I refer are
those in which there really is a uniquely best course of action -- for
Emacs to present a message to the user, and for the user to behave
better --, so entering a debugger at all is just an impediment to the
user's flow.  Using the condition system at all for such cases doesn't
make much sense: the whole purpose of it is to allow programs to defer
to other parts of the program the decision of what course of action to
take, when there are multiple possibilities between which none is
obviously best.

   I have done some work to take these messages into account at the REPL
   (cf. entry 2007-05-14)

Oops!  I was looking at CVS from 2007-05-13.  I shall endeavour to
remember to update CVS before making inquiries on the mailing list...

                          -- 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!)

   [...]

   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.)

It is true that I have an obvious interested in SLIME48, but I think
that it is also worth considering in Common Lisp.  My (possibly wrong)
idea of the architecture of CL Swank is that there is the back end,
which implements non-portable extensions to Common Lisp that are
useful in IDEs, and the implementation of the RPCs.  The back end is
(theoretically) useful independent of the specific integration with
Emacs, and the RPCs are for the most part just wrappers around the
functionality of Common Lisp and the Swank back end necessary to
present information palatably to Emacs.  In my model, the RPC
functions (i.e. everything defined with DEFSLIMEFUN) are the only
places in the code that ABORT-REQUEST should ever be invoked in code,
because they themselves are expected to be invoked only by remote call
from Emacs; everything else should use the condition system to report
problems.

Now, obviously, real errors in RPC implementations should trigger the
debugger, and the debugger is always an acceptable substitute if an
RPC implementation fails to properly check its arguments.  But I think
that it would be preferable for anything invoked by Emacs through the
RPC server to call ABORT-REQUEST with a useful report, and for
anything intended to be invoked by arbitrary Common Lisp clients to
use the condition system.

Personally, in the case of DECODE-KEYWORD-ARG, I'd use the condition
system to report errors: it looks to me like any error there is a bug
worthy of debugging anyway, because it should only ever receive its
arguments from within the Common Lisp system, which is presumably in
an inconsistent state if it yields an invalid argument list.

I could also have a completely wrong idea about this, because I didn't
design it, and never discussed its design at any great length with its
designers; this is just what I have concluded from my understanding of
the code.