[slime-devel] Error signalling and handling in DEFINTERFACE methods?

Peter Seibel peter at gigamonkeys.com
Sun Mar 5 18:17:03 UTC 2006

After being bit for about the billionth time by trying to ,cd to a
file rather than a directory with the result of leaving
*default-pathname-defaults* set to something that doesn't merge will
with others, I decided to see if I could make SLIME protect me from
myself. As a quick proof of concept, I made this change to

Index: swank-allegro.lisp
RCS file: /project/slime/cvsroot/slime/swank-allegro.lisp,v
retrieving revision 1.82
diff -u -r1.82 swank-allegro.lisp
--- swank-allegro.lisp	10 Feb 2006 16:54:01 -0000	1.82
+++ swank-allegro.lisp	5 Mar 2006 18:09:36 -0000
@@ -85,6 +85,8 @@
 (defimplementation set-default-directory (directory)
+  (unless (excl:probe-directory directory)
+    (break "~a not a directory." directory))
   (let ((dir (namestring (setf *default-pathname-defaults* 
                                (truename (merge-pathnames directory))))))
     (excl:chdir dir)
@@ -500,7 +502,7 @@
 (defmethod inspect-for-emacs ((o standard-object) (inspector acl-inspector))
-  (values (format "~A is a standard-object." o) (allegro-inspect o)))
+  (values (format nil "~A is a standard-object." o) (allegro-inspect o)))
 (defun allegro-inspect (o)
   (loop for (d dd) on (inspect::inspect-ctl o)

(Hmmm, the last chunk of that patch looks like some minor bug fix that
I've had lying around that could usefully be applied to the mainline.)

But that raises two questions:

 1) Is there a standard protocol for signalling errors from functions
    that are invoked via comma shortcuts? At the moment simply
    BREAKing does the trick in the sense that I can then abort out of
    the debugger with no harm done but it seems a bit gross.

 2) Is there some clever way to provide a *partial* default
    implementation. That is, I'd like in swank-backend.lisp to do the
    error checking (using a suitably portable replacement for
    EXCL:PROBE-DIRECTORY) before doing the moral equivalent of a
    CALL-NEXT-METHOD to get to the implementation-specific version. A
    literal CALL-NEXT-METHOD won't work, it seems, since although
    DEFIMPLEMENTATION expands to a method, it always expands to a
    method with default (i.e. T) specializations on all its


Peter Seibel           * peter at gigamonkeys.com
Gigamonkeys Consulting * http://www.gigamonkeys.com/
Practical Common Lisp  * http://www.gigamonkeys.com/book/

More information about the slime-devel mailing list