[slime-devel] eval-in-emacs and 'window'-debugger

Antonio Menezes Leitao aml at gia.ist.utl.pt
Sat Aug 28 10:40:17 UTC 2004


Hi everybody,

I noticed that slime provides a function eval-in-emacs that sends a
form to the emacs side where it is evaluated.  However, I would like
to get the results on the lisp side but I always get NIL.

Is there a different swank function for that? (in the
emacs-lisp-interface from Franz I used a lep::eval-in-emacs that did
precisely what I needed).

This is very useful to provide refactoring operations (that operate on
the Lisp side) that need to interact with the user using emacs lisp
operations such as y-or-n-p or read-from-minibuffer.

I know that it might be difficult to find a general scheme to
translate from emacs lisp values to common lisp values but all I need
is symbols, strings, numbers and such.

-----------------

A few years ago I developed a 'window'-debugger and 'window'-inspector
for Ilisp+CMUCL similar to what I used in the Explorer Lisp Machines.
I recently adapted it to Slime+Whatever-Common-Lisp-slime-supports.
If anyone is interested I can post it.  However, I would like to
suggest two changes to Slime in order to improve its portability:

1. The function swank::inspected-parts should provide a recognizable
   value for unbound slots.  Here is one example in SBCL

CL-USER> (defclass c ()
           ((a)))
#<STANDARD-CLASS C>
CL-USER> (swank::inspected-parts (make-instance 'c))
"The object is a STANDARD-OBJECT of type C.
"
(("A" . #:INSPECT-UNBOUND-OBJECT-3530))

and in CLISP

CL-USER> (swank::inspected-parts (make-instance 'c))
"#<COMMON-LISP-USER::C #x20426856>
 standard object
type: COMMON-LISP-USER::C"
(("A" . INSPECT-TMP-PACKAGE-5413::|#<unbound>|))

I know that the returned values are recognizable (e.g., by being the
value of the variable sb-impl::*inspect-unbound-object-marker* or
something similar) but given the fact that it depends on the Common
Lisp being used, it would be preferable if Slime provided a function
that recognizes such value.  If it already does, my apologies.


2. The function swank::frame-locals doesn't distinguish valid locals
   from invalid ones.  I know that not all Common Lisps make that
   distinction but for the ones that make, it would be useful to get
   that information (for Common Lisps that don't provide such
   information a default could be chosen).  Currently, Slime puts a
   :not-available as value which, IMHO, is error-prone.  It would be
   nicer to have an extra field for each local that describes its
   status or (as in 1.) a slime function that recognizes such special
   value or as a third (and not so good) alternative,
   swank::frame-locals should not produce invalid locals.


Thanks in advance,

António Leitão.





More information about the slime-devel mailing list