[slime-devel] New to lisp and slime

[Paul Bowyer]

On 04/02/2011 12:58 AM, Helmut Eller wrote:
> * Paul Bowyer [2011-04-01 16:23] writes:
>
>>> In my learning exercises, I have been using something like:
>>> -----------------------------------------------------------------------------
>>> (eval-when (:compile-toplevel :load-toplevel :execute)
>>>      (if (find-package "CH16")
>>>          (delete-package "CH16"))
>>>      )
>>> (defpackage "CH16"
>>>        (:use "COMMON-LISP" "UTIL")
>>>      (:shadow "LENGTH" "MEMBER" "COUNT")
>>>      (:export "LENGTH" "MEMBER" "BEFORE"
>>>                "NUMBER-LISTP" "SAME-LENGTH1"
>>>                "SAME-LENGTH2" "COUNT")
>>>      )
>>>
>>> (in-package "CH16")
> I think the problem is that the code tries to delete the current
> package, i.e. the package stored in the variable *package*.  You can
> also produce the error in a normal SBCL session without Slime:
>
>    cl-user>  (load (compile-file "x.lisp"))
>    [...]
>    t
>    cl-user>  (in-package ch16)
>    #<package "CH16">
>    ch16>  (load (compile-file "x.lisp"))
>    [...]
>    debugger invoked on a SIMPLE-TYPE-ERROR in thread #<THREAD
>                                                        "initial thread" RUNNING
>                                                        {AA43859}>:
>      *PACKAGE* can't be a deleted package:
>        *PACKAGE* has been reset to #<PACKAGE "COMMON-LISP-USER">.
>    [...]
>
> COMPILE-FILE does something like
> (let ((*package* *package*))
>     <code-that-does-the-rest>)
> so that *package* is automatically reset to the original value at the
> end.  But if *package* is the CH16 package before you call COMPILE-FILE
> and that CH16 package is deleted at compile-time, we end up with a
> deleted package in *package*.
>
> Now, you may ask why *package* is CH16 when using Slime.  That's because
> there is a (in-package ch16) form in the file and Slime tries to be
> friendly and automatically switches to that package.
>
> Yes, this is really confusing.
>
> CLTL2[*] has some good rules to avoid many of those situations:
>
>    In order to guarantee that compiled files can be loaded correctly, the
>    user must ensure that the packages referenced in the file are defined
>    consistently at compile and load time. Conforming Common Lisp programs
>    must satisfy the following requirements.
>
>      - The value of *package* when a top-level form in the file is
>        processed by compile-file must be the same as the value of *package*
>        when the code corresponding to that top-level form in the compiled
>        file is executed by the loader. In particular, any top-level form in
>        a file that alters the value of *package* must change it to a
>        package of the same name at both compile and load time; moreover, if
>        the first non-atomic top-level form in the file is not a call to
>        in-package, then the value of *package* at the time load is called
>        must be a package with the same name as the package that was the
>        value of *package* at the time compile-file was called.
>
>      - For every symbol appearing lexically within a top-level form that
>        was accessible in the package that was the value of *package* during
>        processing of that top-level form at compile time, but whose home
>        package was another package, at load time there must be a symbol
>        with the same name that is accessible in both the load-time
>        *package* and in the package with the same name as the compile-time
>        home package.
>
>      - For every symbol in the compiled file that was an external symbol in
>        its home package at compile time, there must be a symbol with the
>        same name that is an external symbol in the package with the same
>        name at load time.
>
> Some of the package related functions like delete-package, unintern,
> rename-package etc. can lead to those confusing situations.  If
> possible, create the package structure once and don't modify it later.
> Obviously that's not always possible but now you know that you need to
> be careful when messing around with packages.
>
> Helmut
>
> [*] http://www.cs.cmu.edu/afs/cs/project/ai-repository/ai/html/cltl/clm/node224.html#SECTION002910000000000000000
>
>
> _______________________________________________
> slime-devel site list
> slime-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/slime-devel
>
Thank you for the explanation. I had tried:

cl-user> (compile-file "x.lisp")
cl-user> (load "x.fasl")

which worked. I didn't think to try:

cl-user> (load (compile-file "x.lisp"))

so I will be better educated (maybe) for future problems.
Now that I understand the problem, I think I have a working solution, 
but I'll need to test all of my lesson files to be certain.

I'm pleased that I have a place to bring my problems when I run into 
things I don't understand about lisp and slime, but I'll try not to be 
continual pest so as not to be a burden on the mailing list.

Paul