Help: Errors when symbol export list changes in defpackage

Discussion of Common Lisp
Post Reply
chisquare05
Posts: 2
Joined: Sun Jul 03, 2011 6:39 pm

Help: Errors when symbol export list changes in defpackage

Post by chisquare05 » Sun Jul 03, 2011 6:54 pm

I'm using SBCL (1.0.29, though upgrading soon), with quicklisp and asdf(2), on Mac OS X 10.5.8
with Emacs and SLIME.

I have been developing a project with several packages, including a library of code that
I'm using throughout. Everything works fine until I change the list of symbols
that are exported by the package (e.g., I remove a function and take its name out
of the :export list in the defpackage in the file package.lisp, which has all the
defpackage's for the library).

At that point the code will not successfully recompile. I get warnings
of the following form for each such package and each such symbol.

Code: Select all

; caught WARNING:
;   <package-name> also exports the following symbols:
;     (<package-name>:<previously-defined-function-name>)
;   See also:
;     The ANSI Standard, Macro DEFPACKAGE
Although there are no errors listed, only warnings, the system calls this
a fatal problem and refuses to compile. Even stranger:
when I put those (now fake) symbols back in the export list (even without defining
such functions), everything compiles fine!

I recompile with

Code: Select all

(asdf:operate 'asdf:load-op <system> :force t)
I tried deleting the .fasl files for the package but this didn't do the trick.
I don't know where else the information on the old symbol would be stored.
I even reloaded the package file, to no avail.

I'd very much appreciate any help on this. I'm sure I'm missing something simple,
but it's quite frustrating. Thanks!

chisquare05
Posts: 2
Joined: Sun Jul 03, 2011 6:39 pm

Re: Help: Errors when symbol export list changes in defpackage

Post by chisquare05 » Sun Jul 03, 2011 7:30 pm

Update: I restarted the process several times with the same problem. But when I
restarted in a different directory (and in the shell rather than SLIME), the compile
went through. This might be a solution, but not a very satisfying one.
Could there be information saved in the image? Does this mean
that a hard restart in necessary whenever changing the exported symbol list
in a package?

As it is, I'm not finding the package/asdf/quickload combination entirely
transparent. But I'll leave that for another day.

ramarren
Posts: 613
Joined: Sun Jun 29, 2008 4:02 am
Location: Warsaw, Poland
Contact:

Re: Help: Errors when symbol export list changes in defpackage

Post by ramarren » Sun Jul 03, 2011 10:13 pm

chisquare05 wrote:Although there are no errors listed, only warnings, the system calls this
a fatal problem and refuses to compile.
The specification for COMPILE-FILE does specify that warnings except style warnings do count as a compilation failure.
chisquare05 wrote:Even stranger:
when I put those (now fake) symbols back in the export list (even without defining
such functions), everything compiles fine!
That is not at all strange, packages just bind strings to symbols. Symbols in Common Lisp are first class objects which exist independently from anything else, and hence are not in any way "fake", even without functions or variables bound to them. There are use cases where you might want use symbols in a package for their identity, and hence you would export them.
chisquare05 wrote:Could there be information saved in the image?
There will be information about a package saved in the image if you save an image with such information stored in it. There shouldn't be any information about usercode in a core provided by standard installation, unless you load it in as a part of initialization process.
chisquare05 wrote:Does this mean
that a hard restart in necessary whenever changing the exported symbol list
in a package?
The export list of a package can be modified using the EXPORT/UNEXPORT functions. You can also DELETE-PACKAGE and recreate it from scratch. This does not guarantee that all internal references to whatever was bound to symbols in that package will be released though, so it is best to occasionally load a fresh core and reconstruct an entire system from scratch. This is generally recommended anyway to make sure that the system can be rebuilt from source.

Post Reply