From: JP Massar
Subject: Problem with EXPORT semantics
Date:
Message-ID: <3bb38366.91778871@news>
Corman Lisp signals an error, and the hyperspec implies that this is
correct behavior.
Allegro does not signal an error, and common sense implies that this
is correct behavior.
How should this be resolved?
;;;; USING ALLEGRO 5.1
> (make-package "XYZZY" :use nil)
#<The XYZZY package>
> (make-package "PLUGH" :use '("COMMON-LISP" "XYZZY"))
#<The PLUGH package>
> (import '(cl:cons) "XYZZY")
T
> (export '(cl:cons) "XYZZY")
T
>
;;;; USING CORMAN 1.5
(make-package "XYZZY" :use nil)
#<PACKAGE "XYZZY">
(make-package "PLUGH" :use '("COMMON-LISP" "XYZZY"))
#<PACKAGE "PLUGH">
(import '(cl:cons) "XYZZY")
T
(export '(cl:cons) "XYZZY")
;;; An error occurred in function EXPORT:
;;; Error: Cannot export symbol CONS from package #<PACKAGE "XYZZY">,
because package #<PACKAGE "PLUGH"> already already inherits a symbol
named CONS from another package
From the hyperspec:
export makes each symbol accessible to all the packages that use
package. All of these packages are checked for name conflicts: (export
s p) does (find-symbol (symbol-name s) q) for each package q in
(package-used-by-list p). Note that in the usual case of an export
during the initial definition of a package, the result of
package-used-by-list is nil and the name-conflict checking takes
negligible time. When multiple changes are to be made, for example
when export is given a list of symbols, it is permissible for the
implementation to process each change separately, so that aborting
from a name conflict caused by any but the first symbol in the list
does not unexport the first symbol in the list. However, aborting from
a name-conflict error caused by export of one of symbols does not
leave that symbol accessible to some packages and inaccessible to
others; with respect to each of symbols processed, export behaves as
if it were as an atomic operation.
······@alum.mit.edu (JP Massar) writes:
> Corman Lisp signals an error, and the hyperspec implies that this is
> correct behavior.
No, I don't think so.
> (make-package "XYZZY" :use nil)
> #<PACKAGE "XYZZY">
> (make-package "PLUGH" :use '("COMMON-LISP" "XYZZY"))
> #<PACKAGE "PLUGH">
> (import '(cl:cons) "XYZZY")
> T
> (export '(cl:cons) "XYZZY")
> ;;; An error occurred in function EXPORT:
> ;;; Error: Cannot export symbol CONS from package #<PACKAGE "XYZZY">,
> because package #<PACKAGE "PLUGH"> already already inherits a symbol
> named CONS from another package
As far as I can see, it ought to be the same symbol named "CONS", and
that's not a name conflict. The relevant passage is at the start of
ANS 11.1.1.2.5: "Within one package, any particular name can refer to
at most one symbol. A name conflict is said to occur when there would
be more than one candidate symbol.", and later on in the same chapter
this is clarified: "If the same symbol is accessible to a package
through more than one path, there is no name conflict. A symbol cannot
conflict with itself."
So unless there's another CONS that crept in from somewhere, that's a
bug in Corman Lisp.
--
Pekka P. Pirinen
Mail should be private, whether on paper or on disk. Public gatherings
should be a right, whether virtual or in person.
From: JP Massar
Subject: Re: Problem with EXPORT semantics
Date:
Message-ID: <3bb49b80.163496089@news>
Yes, I think that's clear. Thanks.
On 28 Sep 2001 13:45:54 +0100, ···············@globalgraphics.com
(Pekka P. Pirinen) wrote:
>······@alum.mit.edu (JP Massar) writes:
>> Corman Lisp signals an error, and the hyperspec implies that this is
>> correct behavior.
>
>No, I don't think so.
>
>> (make-package "XYZZY" :use nil)
>> #<PACKAGE "XYZZY">
>> (make-package "PLUGH" :use '("COMMON-LISP" "XYZZY"))
>> #<PACKAGE "PLUGH">
>> (import '(cl:cons) "XYZZY")
>> T
>> (export '(cl:cons) "XYZZY")
>> ;;; An error occurred in function EXPORT:
>> ;;; Error: Cannot export symbol CONS from package #<PACKAGE "XYZZY">,
>> because package #<PACKAGE "PLUGH"> already already inherits a symbol
>> named CONS from another package
>
>As far as I can see, it ought to be the same symbol named "CONS", and
>that's not a name conflict. The relevant passage is at the start of
>ANS 11.1.1.2.5: "Within one package, any particular name can refer to
>at most one symbol. A name conflict is said to occur when there would
>be more than one candidate symbol.", and later on in the same chapter
>this is clarified: "If the same symbol is accessible to a package
>through more than one path, there is no name conflict. A symbol cannot
>conflict with itself."
>
>So unless there's another CONS that crept in from somewhere, that's a
>bug in Corman Lisp.
>--
>Pekka P. Pirinen
>Mail should be private, whether on paper or on disk. Public gatherings
>should be a right, whether virtual or in person.