For some reason I have to use this :
(defpackage packagename1)
(use-package 'packagename2)
(in-package packagename1)
(defclass ..... )
instead of this :
(defpackage packagename1 (:use packagename2))
(in-package packagename1)
(defclass ..... )
Second version gives me errors at the first class defined after.
I understood that the two versions are equivalent, aren't they ?
Regards
Matt
--
Matt Koss e-mail: ······@open.ac.uk
Matt Koss <······@open.ac.uk> writes:
> For some reason I have to use this :
>
> (defpackage packagename1)
> (use-package 'packagename2)
> (in-package packagename1)
> (defclass ..... )
>
> instead of this :
>
> (defpackage packagename1 (:use packagename2))
> (in-package packagename1)
> (defclass ..... )
>
> Second version gives me errors at the first class defined after.
> I understood that the two versions are equivalent, aren't they ?
It would help to know the implementation and version and command you
issued that created the problem.
Absent that, I'm betting that maybe you're pre-reading or compiling in
the editor and the system has autocreated the package packagename1 to
allow you to edit a file in that package without actually scanning
your defpackage. The system SHOULD modify the package to add the used
package when it finally sees the definition, but I can imagine it
thinking that since the package already exists, it had better not muck
with it. If this is so, the workaround could be to make sure your
definition file is loaded before entering the editor, though you might
send the vendor a bug report anyway. I've certainly seen implementations
with this bug.
But it might be your problem is wholly different. Answering the questions
in my first paragraph will help clarify that.
In article <············@clyde.open.ac.uk>, Matt Koss
<······@open.ac.uk> wrote:
> For some reason I have to use this :
>
> (defpackage packagename1)
> (use-package 'packagename2)
> (in-package packagename1)
> (defclass ..... )
>
> instead of this :
>
> (defpackage packagename1 (:use packagename2))
> (in-package packagename1)
> (defclass ..... )
>
> Second version gives me errors at the first class defined after.
> I understood that the two versions are equivalent, aren't they ?
They aren't.
See (package-use-list 'packagename1) on both versions.
In the second version there is no package named "COMMON-LISP"
on the package use list. This means that there is no DEFCLASS
(and all the other CL symbols) available in the package.
The reference to DEFCLASS after (in-package packagename1)
triggers the error...
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
In article <····························@news.is-europe.net>,
Rainer Joswig <······@corporate-world.lisp.de> wrote:
>In article <············@clyde.open.ac.uk>, Matt Koss
><······@open.ac.uk> wrote:
>
>> For some reason I have to use this :
>>
>> (defpackage packagename1)
>> (use-package 'packagename2)
>> (in-package packagename1)
>> (defclass ..... )
>>
>> instead of this :
>>
>> (defpackage packagename1 (:use packagename2))
>> (in-package packagename1)
>> (defclass ..... )
>>
>> Second version gives me errors at the first class defined after.
>> I understood that the two versions are equivalent, aren't they ?
>
>They aren't.
>
>See (package-use-list 'packagename1) on both versions.
>
>In the second version there is no package named "COMMON-LISP"
>on the package use list. This means that there is no DEFCLASS
>(and all the other CL symbols) available in the package.
>The reference to DEFCLASS after (in-package packagename1)
>triggers the error...
The detail that Rainer is alluding to, but never actually comes out and
says, is that when you leave out the :USE option in DEFPACKAGE, it defaults
to (:use common-lisp). But if you use :USE, then your list is used as is;
if you want to use the COMMON-LISP package, you have to mention it
explicitly. So your first example is actually equivalent to:
(defpackage packagename1 (:use packagename2 common-lisp))
(in-package packagename1)
(defclass ...)
This has bitten other people in the past, IIRC, although I think it was in
the opposite way -- they left out the :USE option, and expected to get an
unfettered package. What they needed was (:use) to force an empty
use-list.
In retrospect, perhaps the right way to deal with this might have been a
separate :USE-COMMON-LISP option.
--
Barry Margolin, ······@genuity.net
Genuity, Burlington, MA
*** DON'T SEND TECHNICAL QUESTIONS DIRECTLY TO ME, post them to newsgroups.
Please DON'T copy followups to me -- I'll assume it wasn't posted to the group.
In article <················@burlma1-snr2>, Barry Margolin
<······@genuity.net> wrote:
> The detail that Rainer is alluding to, but never actually comes out and
> says, is that when you leave out the :USE option in DEFPACKAGE, it defaults
> to (:use common-lisp).
The default use list is "implementation-dependent/defined", according to
the HyperSpec (was it hyperspec, or HYPERSPEC? ;-) )
--
Rainer Joswig, Hamburg, Germany
Email: ·············@corporate-world.lisp.de
Web: http://corporate-world.lisp.de/
Matt Koss <······@open.ac.uk> writes:
> For some reason I have to use this :
>
> (defpackage packagename1)
> (use-package 'packagename2)
> (in-package packagename1)
> (defclass ..... )
>
> instead of this :
>
> (defpackage packagename1 (:use packagename2))
> (in-package packagename1)
> (defclass ..... )
>
> Second version gives me errors at the first class defined after.
> I understood that the two versions are equivalent, aren't they ?
No, they are not: If you specify the :use option to defpackage, you
are expected to specify _all_ the packages you want to use. Since you
don't specify the common-lisp package, it is not being added to the
package-use-list of your package, hence no defclass, etc.
If you don't specify the :use option, then the default package use
list is used, which in most implementations will include the
common-lisp package (and probably some implementation-specific
packages as well).
When you then do an additonal use-package, the package you specify
will be _added_ to the package-use-list, so common-lisp & co. stay
there.
So add common-lisp to your :use clause, and things will work as
expected. See also the entries for defpackage and use-package in the
HyperSpec.
Regs, Pierre.
--
Pierre R. Mai <····@acm.org> http://www.pmsf.de/pmai/
The most likely way for the world to be destroyed, most experts agree,
is by accident. That's where we come in; we're computer professionals.
We cause accidents. -- Nathaniel Borenstein
* "Pierre R. Mai" <····@acm.org>
| If you don't specify the :use option, then the default package use
| list is used, which in most implementations will include the
| common-lisp package (and probably some implementation-specific
| packages as well).
It may be useful to inspect the list of packages that is in this
default list so you know what you get.
(prog1 (package-use-list (make-package "foobar")) (delete-package "foobar"))
=> (#<package "common-lisp" ("cl" "lisp") 978: 0::>)
Note that this list may differ wildly between implementations, but you
will always find the package "common-lisp" in there.
| When you then do an additonal use-package, the package you specify
| will be _added_ to the package-use-list, so common-lisp & co. stay
| there.
However, note that use-package defaults the package to the current
package, the value of *package*, not the most recently defined
package, as in the user's code, so that instruction is actually
ineffectual, and it all works by accident.
#:Erik
--
ALGORITHM: a procedure for solving a mathematical problem in a finite
number of steps that frequently involves repetition of an operation.
ALGOREISM: a procedure for solving an electoral problem in a finite
number of steps that frequently involves repetition of an operation.