"Dr. Edmund Weitz" wrote:
> I have
> (setq lisp-dont-cache-package t)
> in my .ilisp file. However, if I load the file "test.lisp" that has
> the following contents
> (in-package :cl-user)
> (defpackage :test
> (:use :common-lisp))
> (in-package :test)
> (defun foo (x)
> (foo 3)
> and then put the cursor in front of (FOO 3) and execute
> EVAL-NEXT-SEXP-LISP, I get
> * ;;; Evaluate (foo 3)
> Error in KERNEL:%COERCE-TO-FUNCTION: the function FOO is undefined.
> in the CMUCL buffer which looks as if ILISP has evaluated this form in
> the CL-USER package. I thought that setting LISP-DONT-CACHE-PACKAGE to
> T would force ILISP to always find the most recent IN-PACKAGE
> statement and use that package, i.e. :TEST in this case.
Well, the find-package behavior is a bit complicated ...
If you set lisp-dont-cache-package to T, this just tells ILISP that it
has to compute the package every time it's needed.
Otherwise, it would compute it just once, and cache it.
The current behavior is due to the fact, that ILISP takes the _first_
IN-PACKAGE, if there is no DEFPACKAGE form in front of an IN-PACKAGE.
In that case, it won't look for any more IN-PACKAGE forms.
I think there were some cases, that motivated that, but I don't really
remember the exact case.
Retrieving the package is difficult enough, if there are more than one
If you put the DEFPACKAGE in front of the first IN-PACKAGE, it'll work.
A fix for this problem, such that ILISP will not shortcut during
find-package is actually trivial.
And it seems to work - even for my favourite test-case: MK-DEFSYSTEM!
A patch is attached, and I'd ask people to test this (and that's why
I'm forwarding this to ilisp-devel, too ;)
So, should we change this?
What do you (all) think???
Martin Atzmueller <martin@...>