[slime-devel] Daily ChangeLog diff

Paulo Madeira acelent at gmail.com
Wed Nov 23 00:08:01 UTC 2011


2011/11/22 Helmut Eller:
> Currently we return nil by default.  That way we can
> at least tell that the backend has no strong opinion on the matter and
> we simply use the current value of *package* as fallback.
> (...)
> Basically we are interested in the package that
> was current when the function was compiled.

This is quite interesting. Maybe it should be called "definition
package" instead of "frame package".

I was thinking along the line that `e' in sldb reads (or used to read)
the form in CL-USER (it seems) and evalutes it in the repl's package.
For instance:

(defpackage #:foo)

(defun test ()
  (let ((*package* (find-package '#:foo)))
    (break)))

If you enter "(test)" in the repl while in package CL-USER, press `e'
in frame "break" or "test" and enter "(symbol-package 'sym1)", you get
the CL package.

If you enter "(cl-user::test)" in the repl while in package FOO and do
the rest, you get the FOO package.

In my though, executing `symbol-package' shouldn't even succeed, since
package FOO doesn't use CL. `sdlb-eval-in-frame' would read the form
and execute it with the `*package*' of the current frame.

Ok, after exposing this, my opinion is kind of split. When debugging,
it's mighty handy to just copy-paste a source form and have it be read
in the package where the definition was defined. But there might also
be cases where one really wants to read and evaluate things in the
frame's bound value of `*package*'.

I wasn't considering the chance that an implementation wouldn't have
an accessible dynamic environments for each frame. In this case, it
may be more intuitive to just use the frame's `*package*' for both
reading and evaluating, even if that means always using the most
recent frame's `*package*'.

> The purpose of frame-package was primarily that we can read the names of
> local variables without package prefix.

Maybe there should be an SLDB binding just to get a binding's value ,
e.g. that would try match a variable name no matter its package,
unless there were two same named symbols in different packages, where
CMUCL could use its magic to Guess What You Mean (TM).

PS: please excuse my spaghetti quoting.

Paulo Madeira




More information about the slime-devel mailing list