From joubert at joubster.com  Thu Dec 27 00:36:29 2007
From: joubert at joubster.com (Joubert Nel)
Date: Wed, 26 Dec 2007 19:36:29 -0500
Subject: [Clc-users] Re-loading of ASDF-based system where file,
	that contains	defpackage form, is modified
Message-ID: <1198715789.19260.26.camel@joubert-desktop>

Hi,

I have found a case where SBCL, when loading a set of files via ASDF
(and with Common-Lisp-Controller doing its magic), errors if the file
that contains a defpackage form, is modified inbetween successive
(require) invocations.

I am not sure whether this is expected behavior, but I doubt it.
Moreover, I'm not certain whether this would be an ASDF error or an SBCL
one (my gut says the former), or even a Common Lisp Controller
interference with ASDF.

Steps to reproduce:
1) Create 3 files; one .asd, one package.lisp, and another .lisp file
(let's call this functions.lisp)
2) The defsystem specifies as components the package.lisp and
functions.lisp files
3) The package.lisp file includes a defpackage form while the
functions.lisp file contains a single defun.
4) Now do a (require) on the system - all is OK.
5) Repeat (require) on the system - all is OK.
6) Now edit the package.lisp file (e.g. add a (format) form) and save.
7) When you now (require) the system, an error condition,
ASDF:COMPILE-FAILED occurs. I attach the backtrace (condition.txt)
information.

The only workaround is to evaluate a (delete-package) form after you
change the package.lisp, but before you do another (require).

Attached are 3 files that demonstrate this problem.
1) (require :pak)
2) Edit the package.lisp and save
3) (require :pak) --> boom!

Platform:
SBCL 1.0.11.debian (on Ubuntu).
Common Lisp Controller 6.12
CL-Asdf 1.109-2

Any ideas?

Joubert


-------------- next part --------------
A non-text attachment was scrubbed...
Name: pak.asd
Type: text/lisp-sysdef
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071226/3b4afd69/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: package.lisp
Type: text/lisp-source
Size: 123 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071226/3b4afd69/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: functions.lisp
Type: text/lisp-source
Size: 130 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071226/3b4afd69/attachment-0002.bin 
-------------- next part --------------
erred while invoking #<COMPILE-OP NIL {AE191E1}> on
#<CL-SOURCE-FILE "package" {B065A49}>
   [Condition of type ASDF:COMPILE-FAILED]

Restarts:
 0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {AE191E1}> on #<ASDF:CL-SOURCE-FILE "package" {B065A49}>.
 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {AE191E1}> on #<ASDF:CL-SOURCE-FILE "package" {B065A49}> as having been successful.
 2: [ABORT] Return to SLIME's top level.
 3: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B436311}>)

Backtrace:
  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM
       (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
      #<unavailable argument>
      #<unavailable argument>
      #<ASDF:COMPILE-OP NIL {AE191E1}>
      #<ASDF:CL-SOURCE-FILE "package" {B065A49}>)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {AE191E1}>
        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "package" {B065A49}>
  1: ((LAMBDA
          (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
           SB-PCL::.ARG1.))
      #<unavailable argument>
      #<unavailable argument>
      #<ASDF:COMPILE-OP NIL {AE191E1}>
      #<ASDF:CL-SOURCE-FILE "package" {B065A49}>)
  2: ((LAMBDA ()))
      [No Locals]
  3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
      [No Locals]
  4: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645281D}>
      T)
      Locals:
        SB-DEBUG::ARG-0 = #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645281D}>
        SB-DEBUG::ARG-1 = T
  5: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
  6: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
  7: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645290D}>)
  8: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
      #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {B645298D}>
      #S(SB-THREAD:MUTEX
         :NAME "big compiler lock"
         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B436311}>
         :STATE 1))
  9: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {AE247FD}>)
 10: (ASDF:OPERATE ASDF:LOAD-OP :PAK)
 11: (ASDF::MODULE-PROVIDE-ASDF :PAK)
 12: ((LAMBDA (#:G[REQUIRE]18)) ASDF::MODULE-PROVIDE-ASDF)
 13: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1
      #<CLOSURE (LAMBDA #) {ADC5D8D}>
      (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB))
 14: (REQUIRE :PAK NIL)
 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE :PAK) #<NULL-LEXENV>)
 16: (SWANK::EVAL-REGION
      "(require :pak)
     ")
 17: ((LAMBDA ()))
 18: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {ADC5995}>)
 19: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {ADC597D}>)
 20: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {ADC597D}>)
 21: (SWANK::REPL-EVAL
      "(require :pak)
     ")
 22: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (SWANK:LISTENER-EVAL "(require :pak)
     ")
      #<NULL-LEXENV>)
 23: ((LAMBDA ()))
 24: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<CLOSURE (LAMBDA #) {ADC584D}>)
 25: ((LAMBDA ()))
 26: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<FUNCTION (LAMBDA #) {B9FF66D}>)
 27: (SWANK::CALL-WITH-REDIRECTED-IO
      #<SWANK::CONNECTION {B31DE89}>
      #<CLOSURE (LAMBDA #) {ADC5795}>)
 28: (SWANK::CALL-WITH-CONNECTION
      #<SWANK::CONNECTION {B31DE89}>
      #<FUNCTION (LAMBDA #) {B9FF66D}>)
 29: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {B31DE89}>)
 30: (SWANK::REPL-LOOP #<SWANK::CONNECTION {B31DE89}>)
 31: (SWANK::REPL-LOOP #<SWANK::CONNECTION {B31DE89}>)
 32: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B4450A5}>)
 33: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 34: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645309D}>
      T)
 35: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
 36: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
 37: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645318D}>)
 38: (SB-THREAD::CALL-WITH-MUTEX
      #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6453215}>
      #S(SB-THREAD:MUTEX
         :NAME "thread result lock"
         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B436311}>
         :STATE 1)
      #<SB-THREAD:THREAD "repl-thread" {B436311}>
      T)
 39: ((LAMBDA ()))
 40: ("foreign function: #x806398C")
 41: ("foreign function: #x8051E61")
 42: ("foreign function: #x805B44D")
 43: ("foreign function: #xB7FB84FB")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071226/3b4afd69/attachment.pgp 

From rudi at constantly.at  Thu Dec 27 08:32:56 2007
From: rudi at constantly.at (Rudi Schlatte)
Date: Thu, 27 Dec 2007 16:32:56 +0800
Subject: [Clc-users] [Sbcl-devel] Re-loading of ASDF-based system where
	file, that contains	defpackage form, is modified
In-Reply-To: <1198715789.19260.26.camel@joubert-desktop>
References: <1198715789.19260.26.camel@joubert-desktop>
Message-ID: <BF2A81B4-74C7-4A4E-B168-1282D493273F@constantly.at>

Hi Joubert,

I tried to reproduce your problem: I took the files you sent,  
commented out the second form in package.lisp, loaded via require,  
added the the form again and reloaded via require.  Both lisp files  
were recompiled and reloaded without errors.

Note that the file condition.txt that you attached does not contain  
the actual error output, just asdf telling you (via cerror) that there  
was some problem earlier.  If you send a complete transcript, starting  
with the line (require :pak) entered by you at the REPL, I can have a  
look - otherwise I can only say "works for me", unfortunately ...

Cheers,

Rudi



From joubert at joubster.com  Thu Dec 27 16:43:28 2007
From: joubert at joubster.com (Joubert Nel)
Date: Thu, 27 Dec 2007 11:43:28 -0500
Subject: [Clc-users] [Sbcl-devel] Re-loading of ASDF-based system where
	file, that	contains	defpackage form, is modified
In-Reply-To: <BF2A81B4-74C7-4A4E-B168-1282D493273F@constantly.at>
References: <1198715789.19260.26.camel@joubert-desktop>
	<BF2A81B4-74C7-4A4E-B168-1282D493273F@constantly.at>
Message-ID: <1198773808.19260.61.camel@joubert-desktop>

Hi Rudi,

Thanks for taking the time to look at this.

On Thu, 2007-12-27 at 16:32 +0800, Rudi Schlatte wrote:
> Hi Joubert,
> 
> I tried to reproduce your problem: I took the files you sent,  
> commented out the second form in package.lisp, loaded via require,  
> added the the form again and reloaded via require.  Both lisp files  
> were recompiled and reloaded without errors.

Since you're not seeing the error, here's a variation where I hope you
will:

Attached are the same files with a slight modification.
Functions.lisp has another (defun) and and an explicit (export) form.

To repro:
1) Do a (require).
2) Now comment out the (format) form in the package.lisp file and save. 
3) Evaluate (require). Boom!


I received a note from Christophe mentioning that the result when
changing a (defpackage) form inbetween evaluating successive (require)
forms, is undefined. 

However, I'm *not* modifying the (defpackage) form itself, merely stuff
inside the package. It seems like a subtle, but definite distinction.

(Note: I found this behavior in the project I'm currently working on,
and the attached example is not an exact replica of my code, but shows
the same end-result.)


> Note that the file condition.txt that you attached does not contain  
> the actual error output, just asdf telling you (via cerror) that there  
> was some problem earlier.  If you send a complete transcript, starting  
> with the line (require :pak) entered by you at the REPL, I can have a  
> look - otherwise I can only say "works for me", unfortunately ...

Here is the output when I evaluate (require :pak) after making the
changes to functions.lisp and package.lisp. 

I get the content of the condition.txt file, and if I choose the "abort"
restart, see this:

CL-USER> (require :pak)
; compiling file "/tank/code/lisp/test-packaging/package.lisp" (written
27 DEC 2007 11:24:10 AM):
; compiling (IN-PACKAGE :CL-USER)
; compiling (DEFPACKAGE :PAK ...)
; 
; caught WARNING:
;   PAK also exports the following symbols:
;     (PAK:FUNC3)
;   See also:
;     The ANSI Standard, Macro DEFPACKAGE

; /var/cache/common-lisp-controller/1000/sbcl/local/tank/code/lisp/test-packaging/package.fasl written
; compilation finished in 0:00:00
WARNING:
   COMPILE-FILE warned while performing #<COMPILE-OP NIL {B0EED91}> on
   #<CL-SOURCE-FILE "package" {AA23AA1}>.
; 
; compilation unit aborted
;   caught 1 fatal ERROR condition
;   caught 1 WARNING condition
; Evaluation aborted.
CL-USER> 

If I choose the "accept" restart, then there's no indication of an error
condition.

Hope this helps.



Joubert
-------------- next part --------------
erred while invoking #<COMPILE-OP NIL {AE191E1}> on
#<CL-SOURCE-FILE "package" {B065A49}>
   [Condition of type ASDF:COMPILE-FAILED]

Restarts:
 0: [RETRY] Retry performing #<ASDF:COMPILE-OP NIL {AE191E1}> on #<ASDF:CL-SOURCE-FILE "package" {B065A49}>.
 1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {AE191E1}> on #<ASDF:CL-SOURCE-FILE "package" {B065A49}> as having been successful.
 2: [ABORT] Return to SLIME's top level.
 3: [TERMINATE-THREAD] Terminate this thread (#<THREAD "repl-thread" {B436311}>)

Backtrace:
  0: ((SB-PCL::FAST-METHOD ASDF:PERFORM
       (ASDF:COMPILE-OP ASDF:CL-SOURCE-FILE))
      #<unavailable argument>
      #<unavailable argument>
      #<ASDF:COMPILE-OP NIL {AE191E1}>
      #<ASDF:CL-SOURCE-FILE "package" {B065A49}>)
      Locals:
        SB-DEBUG::ARG-0 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-1 = :<NOT-AVAILABLE>
        SB-DEBUG::ARG-2 = #<ASDF:COMPILE-OP NIL {AE191E1}>
        SB-DEBUG::ARG-3 = #<ASDF:CL-SOURCE-FILE "package" {B065A49}>
  1: ((LAMBDA
          (SB-PCL::.PV. SB-PCL::.NEXT-METHOD-CALL. SB-PCL::.ARG0.
           SB-PCL::.ARG1.))
      #<unavailable argument>
      #<unavailable argument>
      #<ASDF:COMPILE-OP NIL {AE191E1}>
      #<ASDF:CL-SOURCE-FILE "package" {B065A49}>)
  2: ((LAMBDA ()))
      [No Locals]
  3: ((FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK))
      [No Locals]
  4: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645281D}>
      T)
      Locals:
        SB-DEBUG::ARG-0 = #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645281D}>
        SB-DEBUG::ARG-1 = T
  5: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
  6: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
  7: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645290D}>)
  8: (SB-THREAD::CALL-WITH-RECURSIVE-LOCK
      #<CLOSURE (FLET SB-THREAD::WITH-RECURSIVE-LOCK-THUNK) {B645298D}>
      #S(SB-THREAD:MUTEX
         :NAME "big compiler lock"
         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B436311}>
         :STATE 1))
  9: (SB-C::%WITH-COMPILATION-UNIT #<CLOSURE (LAMBDA #) {AE247FD}>)
 10: (ASDF:OPERATE ASDF:LOAD-OP :PAK)
 11: (ASDF::MODULE-PROVIDE-ASDF :PAK)
 12: ((LAMBDA (#:G[REQUIRE]18)) ASDF::MODULE-PROVIDE-ASDF)
 13: (SB-IMPL::%MAP-FOR-EFFECT-ARITY-1
      #<CLOSURE (LAMBDA #) {ADC5D8D}>
      (ASDF::MODULE-PROVIDE-ASDF SB-IMPL::MODULE-PROVIDE-CONTRIB))
 14: (REQUIRE :PAK NIL)
 15: (SB-INT:SIMPLE-EVAL-IN-LEXENV (REQUIRE :PAK) #<NULL-LEXENV>)
 16: (SWANK::EVAL-REGION
      "(require :pak)
     ")
 17: ((LAMBDA ()))
 18: (SWANK::TRACK-PACKAGE #<CLOSURE (LAMBDA #) {ADC5995}>)
 19: ((LAMBDA (SWANK-BACKEND::FN)) #<CLOSURE (LAMBDA #) {ADC597D}>)
 20: (SWANK::CALL-WITH-BUFFER-SYNTAX #<CLOSURE (LAMBDA #) {ADC597D}>)
 21: (SWANK::REPL-EVAL
      "(require :pak)
     ")
 22: (SB-INT:SIMPLE-EVAL-IN-LEXENV
      (SWANK:LISTENER-EVAL "(require :pak)
     ")
      #<NULL-LEXENV>)
 23: ((LAMBDA ()))
 24: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<CLOSURE (LAMBDA #) {ADC584D}>)
 25: ((LAMBDA ()))
 26: ((LAMBDA (SWANK-BACKEND::HOOK SWANK-BACKEND::FUN))
      #<FUNCTION SWANK:SWANK-DEBUGGER-HOOK>
      #<FUNCTION (LAMBDA #) {B9FF66D}>)
 27: (SWANK::CALL-WITH-REDIRECTED-IO
      #<SWANK::CONNECTION {B31DE89}>
      #<CLOSURE (LAMBDA #) {ADC5795}>)
 28: (SWANK::CALL-WITH-CONNECTION
      #<SWANK::CONNECTION {B31DE89}>
      #<FUNCTION (LAMBDA #) {B9FF66D}>)
 29: (SWANK::HANDLE-REQUEST #<SWANK::CONNECTION {B31DE89}>)
 30: (SWANK::REPL-LOOP #<SWANK::CONNECTION {B31DE89}>)
 31: (SWANK::REPL-LOOP #<SWANK::CONNECTION {B31DE89}>)
 32: (SWANK::CALL-WITH-BINDINGS NIL #<CLOSURE (LAMBDA #) {B4450A5}>)
 33: ((FLET SB-THREAD::WITH-MUTEX-THUNK))
 34: (SB-UNIX::CALL-WITH-LOCAL-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITH-LOCAL-INTERRUPTS-THUNK) {B645309D}>
      T)
 35: ((FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) T)
 36: ((FLET SB-UNIX::RUN-WITHOUT-INTERRUPTS))
 37: (SB-UNIX::CALL-WITHOUT-INTERRUPTS
      #<CLOSURE (FLET SB-UNIX::WITHOUT-INTERRUPTS-THUNK) {B645318D}>)
 38: (SB-THREAD::CALL-WITH-MUTEX
      #<CLOSURE (FLET SB-THREAD::WITH-MUTEX-THUNK) {B6453215}>
      #S(SB-THREAD:MUTEX
         :NAME "thread result lock"
         :%OWNER #<SB-THREAD:THREAD "repl-thread" {B436311}>
         :STATE 1)
      #<SB-THREAD:THREAD "repl-thread" {B436311}>
      T)
 39: ((LAMBDA ()))
 40: ("foreign function: #x806398C")
 41: ("foreign function: #x8051E61")
 42: ("foreign function: #x805B44D")
 43: ("foreign function: #xB7FB84FB")
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pak.asd
Type: text/lisp-sysdef
Size: 188 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071227/48adf702/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: package.lisp
Type: text/lisp-source
Size: 123 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071227/48adf702/attachment-0001.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: functions.lisp
Type: text/lisp-source
Size: 184 bytes
Desc: not available
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071227/48adf702/attachment-0002.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.alioth.debian.org/pipermail/clc-users/attachments/20071227/48adf702/attachment.pgp 

From jsnell at iki.fi  Thu Dec 27 17:10:29 2007
From: jsnell at iki.fi (Juho Snellman)
Date: 27 Dec 2007 19:10:29 +0200
Subject: [Clc-users] [Sbcl-devel] Re-loading of ASDF-based system where
	file, that	contains	defpackage form, is modified
In-Reply-To: <1198773808.19260.61.camel@joubert-desktop>
References: <1198715789.19260.26.camel@joubert-desktop>
	<BF2A81B4-74C7-4A4E-B168-1282D493273F@constantly.at>
	<1198773808.19260.61.camel@joubert-desktop>
Message-ID: <87abnwqd16.fsf@vasara.proghammer.com>

Joubert Nel <joubert at joubster.com> writes:
> I received a note from Christophe mentioning that the result when
> changing a (defpackage) form inbetween evaluating successive (require)
> forms, is undefined. 
> 
> However, I'm *not* modifying the (defpackage) form itself, merely stuff
> inside the package. It seems like a subtle, but definite distinction.

It doesn't seem like a very relevant distinction though, in light of
what the spec actually says:

  If defined-package-name already refers to an existing package, the
  name-to-package mapping for that name is not changed. If the new
  definition is at variance with the current state of that package,
  the consequences are undefined; an implementation might choose to
  modify the existing package to reflect the new definition.

Note that it's not a matter of modifying the defpackage form, it's a
matter of modifying the state of the package in any way, without
having it be reflected in a defpackage form that's evaluated in the
future.

-- 
Juho Snellman