I've stumbled on a problem when trying to redefine a package. I'm
writing a singly-linked list package:
(defpackage :sda-list
(:import-from :cl :defclass :defmethod :in-package :do :not :1+)
(:export :slist :slist-link))
The problem is, if I've compiled (using SLIME/SBCL) and loaded that
definition, trying to recompile it triggers the following error:
The function :IMPORT-FROM is undefined.
[Condition of type COMMON-LISP:UNDEFINED-FUNCTION]
I tried to add :import-from to the :import-from list but then:
no symbol named "IMPORT-FROM" in "COMMON-LISP"
[Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]
Confusingly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> I've stumbled on a problem when trying to redefine a package. I'm
> writing a singly-linked list package:
>
> (defpackage :sda-list
> (:import-from :cl :defclass :defmethod :in-package :do :not :1+)
> (:export :slist :slist-link))
>
> The problem is, if I've compiled (using SLIME/SBCL) and loaded that
> definition, trying to recompile it triggers the following error:
>
> The function :IMPORT-FROM is undefined.
> [Condition of type COMMON-LISP:UNDEFINED-FUNCTION]
If I have a file like this:
(defpackage :test
(:import-from :cl :defclass :defmethod :in-package :do :not :1+))
(in-package :test)
..and I evaluate it twice (ie. press C-c-k twice), it fails the second
time because after the first evaluation the package `test' no longer
have implicit access to the symbol `cl:defpackage' and since it tries
to evaluate all arguments to what it assume is a _function_
`test:defpackage' in left-to-right order it starts with evaluating what
it thinks is a function-call:
(:import-from :cl ....etc.)
Take a look at special forms and macros, and how they differ from
functions in Practical Common Lisp, here:
http://gigamonkeys.com/book/syntax-and-semantics.html
What you could do is this:
(defpackage :test
(:import-from :cl :defpackage :defclass :defmethod :in-package :do
:not :1+))
(in-package :test)
When you evaluate that twice, the package `test' will now have access
to the _special form_ `cl:defpackage' and Lisp will no longer evaluate
all arguments before executing, but instead follow the "special" rules
for what arguments `cl:defpackage' should evaluate.
You could also do:
(cl:defpackage :test
(:import-from :cl :defclass :defmethod :in-package :do :not :1+))
(in-package :test)
..since then Lisp would know that you mean `cl:defpackage' explicitly
and not assume you mean something that should or might be defined later
in `test'.
What I normally do is this:
(defpackage :test
(:use :cl))
(in-package :test)
..since I most likely would like to use many/all of the tools in `cl'
anyway.
> I tried to add :import-from to the :import-from list but then:
>
> no symbol named "IMPORT-FROM" in "COMMON-LISP"
> [Condition of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]
`:import-from' (or `import-from' since `:import-from' is a designator)
does not reside in the CL-package. It resides in the "keyword"-package.
You want to read this:
http://gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html#how-the-reader-uses-packages
Hope this is somewhat understandable.
--
mvh, Lars Rune Nøstdal
http://lars.nostdal.org/
Le Mon, 24 Jul 2006 03:42:27 -0700, Lars Rune Nøstdal a écrit :
> Take a look at special forms and macros, and how they differ from
> functions in Practical Common Lisp, here:
> http://gigamonkeys.com/book/syntax-and-semantics.html
I've already read this, but I ain't that familiar with Lisp evaluation
rules to make the link myself with that error.
> You could also do:
>
> (cl:defpackage :test (:import-from :cl :defclass :defmethod
> :in-package :do :not :1+))
OK. Maybe I'll fully qualify that single form, or I'll use a qualified
version in the REPL...
> You want to read this:
> http://gigamonkeys.com/book/programming-in-the-large-packages-and-symbols.html#how-the-reader-uses-packages
I'm just finishing the chapters on CLOS. ;-)
> Hope this is somewhat understandable.
Totally, thanks!
Gratefully,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
What package is the defpackage itself in? Is it possible the
defpackage form is not available, so (:import-from ...) is treated as
a function call.
>>>>> "Pierre" == Pierre THIERRY <···········@levallois.eu.org> writes:
Pierre> I've stumbled on a problem when trying to redefine a
Pierre> package. I'm writing a singly-linked list package:
Pierre> (defpackage :sda-list (:import-from :cl :defclass
Pierre> :defmethod :in-package :do :not :1+) (:export :slist
Pierre> :slist-link))
Pierre> The problem is, if I've compiled (using SLIME/SBCL) and
Pierre> loaded that definition, trying to recompile it triggers
Pierre> the following error:
Pierre> The function :IMPORT-FROM is undefined. [Condition of
Pierre> type COMMON-LISP:UNDEFINED-FUNCTION]
Pierre> I tried to add :import-from to the :import-from list but
Pierre> then:
Pierre> no symbol named "IMPORT-FROM" in "COMMON-LISP" [Condition
Pierre> of type SB-KERNEL:SIMPLE-PACKAGE-ERROR]
Pierre> Confusingly, Nowhere man -- ···········@levallois.eu.org
Pierre> OpenPGP 0xD9D50D8A
--
John Williams
Le Mon, 24 Jul 2006 10:57:02 +0100, Dr. John A.R. Williams a écrit :
> What package is the defpackage itself in? Is it possible the
> defpackage form is not available, so (:import-from ...) is treated as
> a function call.
But the first call to defpackage works... BTW, I'm in the CL-USER
package, IIUC.
Quickly,
Nowhere man
--
···········@levallois.eu.org
OpenPGP 0xD9D50D8A
Pierre THIERRY wrote:
> Le Mon, 24 Jul 2006 10:57:02 +0100, Dr. John A.R. Williams a écrit :
>> What package is the defpackage itself in? Is it possible the
>> defpackage form is not available, so (:import-from ...) is treated as
>> a function call.
>
> But the first call to defpackage works... BTW, I'm in the CL-USER
> package, IIUC.
Make that explicit:
(in-package :cl-user)
(defpackage ...)
Pascal
--
My website: http://p-cos.net
Closer to MOP & ContextL:
http://common-lisp.net/project/closer/
Pascal Costanza <··@p-cos.net> writes:
> Pierre THIERRY wrote:
>> But the first call to defpackage works... BTW, I'm in the CL-USER
>> package, IIUC.
>
> Make that explicit:
>
> (in-package :cl-user)
^^^^^^^^^^
I suggest (cl:in-package :cl-user), because the bare "in-package" is
vulnerable to exactly the same problem as the bare "defpackage".
> (defpackage ...)
Christophe
Pierre THIERRY <···········@levallois.eu.org> writes:
> (defpackage :sda-list
> (:import-from :cl :defclass :defmethod :in-package :do :not :1+)
> (:export :slist :slist-link))
>
> The problem is, if I've compiled (using SLIME/SBCL) and loaded that
> definition, trying to recompile it triggers the following error:
>
> The function :IMPORT-FROM is undefined.
> [Condition of type COMMON-LISP:UNDEFINED-FUNCTION]
At a guess, you are working in your own SDA-LIST package, so instead
of sending cl:defpackage, recompiling this definition will send to
your lisp a call to sda-list::defpackage, which is not defined as a
macro. So your lisp will attempt to call it as a function, which
means evaluating its arguments in left-to-right order; the first
argument is (:import-from :cl ...), and again :import-from is not
defined as a macro, so it will attempt to evaluate all its arguments
(which works, as they're all keywords) and call it as a function
(which fails, because it's not defined).
To fix this in your above form, use cl:defpackage; in general, it's
probably easier to (:use :common-lisp) and (if necessary) shadow the
symbols you /don't/ want, rather than cherry-pick the ones you do.
Christophe