The following issue came up in writing tests.
In section 11.1.2, we have:
This section describes the packages that are available in
every conforming implementation. A summary of the names and
nicknames of those standardized packages is given in the next figure.
Name Nicknames
COMMON-LISP CL
COMMON-LISP-USER CL-USER
KEYWORD none
Figure 11-2. Standardized Package Names
The question is: is this intended to be an exhaustive list of the nicknames
of the standardized packages, or can a conforming implementation have
additional nicknames?
Implementations have commonly made LISP a nickname for the COMMON-LISP
package, USER a nickname for COMMON-LISP-USER, and "" (the empty string)
a nickname for the KEYWORD package.
Paul
From: james anderson
Subject: Re: Standardized package nicknames
Date:
Message-ID: <3EF6BE0A.358E215@setf.de>
"Paul F. Dietz" wrote:
>
> The following issue came up in writing tests.
>
...
>
> Implementations have commonly made LISP a nickname for the COMMON-LISP
> package, USER a nickname for COMMON-LISP-USER, and "" (the empty string)
> a nickname for the KEYWORD package.
i'd be curious how "common" that last variation is.
i'd also be curious about a distinction between "making it a nickname" and
requiring that it be a nickname.
...
james anderson wrote:
> i'd be curious how "common" that last variation is.
ACL does it and cmucl/sbcl used to do it.
> i'd also be curious about a distinction between "making it a nickname" and
> requiring that it be a nickname.
By the former I was refering to what individual implementations had done,
not by what the space necessarily required them to do.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> james anderson wrote:
>
> > i'd be curious how "common" that last variation is.
>
> ACL does it and cmucl/sbcl used to do it.
Is a newer version of CMUCL than 18e released? If not, then I would
caution you not to say that it "used to do it", because otherwise the
new behavior hasn't been tested against legacy code.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> Is a newer version of CMUCL than 18e released? If not, then I would
> caution you not to say that it "used to do it", because otherwise the
> new behavior hasn't been tested against legacy code.
I'm refering to the most recent post-18e binary on cmucl.cons.org (and
its mirrors).
Paul
From: james anderson
Subject: Re: Standardized package nicknames
Date:
Message-ID: <3EF77A6E.2E38D69B@setf.de>
"Paul F. Dietz" wrote:
>
> james anderson wrote:
>
> > i'd be curious how "common" that last variation is.
>
> ACL does it and cmucl/sbcl used to do it.
>
> > i'd also be curious about a distinction between "making it a nickname" and
> > requiring that it be a nickname.
>
> By the former I was refering to what individual implementations had done,
> not by what the [spec] necessarily required them to do.
the distinction is intended to apply to implementations. as another poster
noted, if an implementation makes it a nickname, rename-package should support
any changes which do not violate the spec.
if, on the other hand, an implementation requires the nicname, it the same
order of non-conformance as additional symbols in the common-lisp package.
Marco Antoniotti wrote:
>
...
> Wouldn't "" as a nickname for the "KEYWORD" package break CL-XML?
>
> I would be very happy to just have '() as value for
> (PACKAGE-NICKNAMES "KEYWORD").
>
that (one-time) issue was behind my question. my recollection of the problem
reports is that it was at one point impossible to change the cmucl keyword
package's nickname to remove "". at one point that was a problem. it should
not be a problem with the present version.
...
james anderson wrote:
>
> "Paul F. Dietz" wrote:
>
> >The following issue came up in writing tests.
> >
>
> ...
>
> >Implementations have commonly made LISP a nickname for the COMMON-LISP
> >package, USER a nickname for COMMON-LISP-USER, and "" (the empty string)
> >a nickname for the KEYWORD package.
>
>
> i'd be curious how "common" that last variation is.
>
> i'd also be curious about a distinction between "making it a nickname" and
> requiring that it be a nickname.
>
> ...
Wouldn't "" as a nickname for the "KEYWORD" package break CL-XML?
I would be very happy to just have '() as value for
(PACKAGE-NICKNAMES "KEYWORD").
--
Marco Antoniotti
Marco Antoniotti <·······@cs.nyu.edu> writes:
> james anderson wrote:
>
> >
> > "Paul F. Dietz" wrote:
> >
> > >The following issue came up in writing tests.
> > >
> >
> > ...
> >
> > >Implementations have commonly made LISP a nickname for the COMMON-LISP
> > >package, USER a nickname for COMMON-LISP-USER, and "" (the empty string)
> > >a nickname for the KEYWORD package.
> >
> >
> > i'd be curious how "common" that last variation is.
> >
> > i'd also be curious about a distinction between "making it a nickname" and
> > requiring that it be a nickname.
> >
> > ...
>
>
> Wouldn't "" as a nickname for the "KEYWORD" package break CL-XML?
>
> I would be very happy to just have '() as value for
> (PACKAGE-NICKNAMES "KEYWORD").
Would you be happy using NIL:X or KEYWORD:X instead of :X as the name for
keywords? The reason "" is a valid name is to make it easy to explain :X
as a generalization of the infix colon in packagename:symbolname.
Kent M Pitman <······@world.std.com> writes:
> Would you be happy using NIL:X or KEYWORD:X instead of :X as the name for
> keywords? The reason "" is a valid name is to make it easy to explain :X
> as a generalization of the infix colon in packagename:symbolname.
If I read the spec correctly, 2.3.5 requires :X to mean
KEYWORD:X regardless of whether "" is a nickname for the KEYWORD
package. In contrast, ||:X should be affected by the nickname.
"Paul F. Dietz" <·····@dls.net> writes:
> The following issue came up in writing tests.
>
> In section 11.1.2, we have:
>
> This section describes the packages that are available in
> every conforming implementation. A summary of the names and
> nicknames of those standardized packages is given in the next figure.
>
> Name Nicknames
> COMMON-LISP CL
> COMMON-LISP-USER CL-USER
> KEYWORD none
>
> Figure 11-2. Standardized Package Names
>
> The question is: is this intended to be an exhaustive list of the nicknames
> of the standardized packages, or can a conforming implementation have
> additional nicknames?
My own claim is that it is unspecified and can be interpreted both ways.
My hope is that we can interpret it as inexhaustive.
> Implementations have commonly made LISP a nickname for the COMMON-LISP
> package, USER a nickname for COMMON-LISP-USER, and "" (the empty string)
> a nickname for the KEYWORD package.
As the implementor who had this conversation with Paul, I'd like to
emphasize a consistency and compatibility point-of-view: Those
implementations of CL which are older and have gone through the
CLtL1 to CLtL2 and finally to ANS have a large legacy code base
running on them. Because the original names of COMMON-LISP and
COMMON-LISP-USER packages were LISP and USER, respectively, and
we made these nicknames for the new package names as we moved to
ANS, so that programs which had e.g. lisp:car in its source would
not have to be changed as much in transition. Now, there may
still be legacy code in effect today which has already had
CLtL1-isms taken out, but which still qualify these two packages
in the old style. I would be concerned about the possibility of
such legacy code suddenly breaking if this change were made.
The presence of these nicknames in these packages is not necessarily
a permanent thing; the potential conflict in naming with other
dialects of lisp (which might themselves have a "LISP" package)
can easily be solved by a simple renaming:
(rename-package (find-package "CL") "COMMON-LISP" '("CL"))
This works both in Allegro CL and CMUCL 18e, both of which include
the "LISP" nickname (although in Allegro CL you have to wrap it
in a without-package-locks form or else continue from the cerror
break).
I would prefer that we consider such additional nicknames to be
extensions, rather than nonconformances.
--
Duane Rettig ·····@franz.com Franz Inc. http://www.franz.com/
555 12th St., Suite 1450 http://www.555citycenter.com/
Oakland, Ca. 94607 Phone: (510) 452-2000; Fax: (510) 452-0182
Duane Rettig wrote:
> As the implementor who had this conversation with Paul, I'd like to
> emphasize a consistency and compatibility point-of-view: Those
> implementations of CL which are older and have gone through the
> CLtL1 to CLtL2 and finally to ANS have a large legacy code base
> running on them. Because the original names of COMMON-LISP and
> COMMON-LISP-USER packages were LISP and USER, respectively, and
> we made these nicknames for the new package names as we moved to
> ANS, so that programs which had e.g. lisp:car in its source would
> not have to be changed as much in transition. Now, there may
> still be legacy code in effect today which has already had
> CLtL1-isms taken out, but which still qualify these two packages
> in the old style. I would be concerned about the possibility of
> such legacy code suddenly breaking if this change were made.
The implementation could have a LISP package that exports all
the external symbols of the COMMON-LISP package (LISP could import
them from COMMON-LISP, COMMON-LISP could inport them from LISP, both
could import them from a third package, or some combination of
these.) This would be compatible with even a strict reading
of the standard.
Programs that did something like
(EQ (FIND-PACKAGE "LISP") (FIND-PACKAGE "COMMON-LISP"))
or perhaps this
(EQ (SYMBOL-PACKAGE X) (FIND-PACKAGE "LISP"))
would still break, but I imagine this is a smaller set
of programs than those that just use LISP in the package
prefix of symbols. The latter could be made compatible by
making LISP the home package of the external symbols
of COMMON-LISP.
Paul
"Paul F. Dietz" <·····@dls.net> writes:
> Duane Rettig wrote:
>
> > As the implementor who had this conversation with Paul, I'd like to
> > emphasize a consistency and compatibility point-of-view: Those
> > implementations of CL which are older and have gone through the
> > CLtL1 to CLtL2 and finally to ANS have a large legacy code base
> > running on them. Because the original names of COMMON-LISP and
> > COMMON-LISP-USER packages were LISP and USER, respectively, and
> > we made these nicknames for the new package names as we moved to
> > ANS, so that programs which had e.g. lisp:car in its source would
> > not have to be changed as much in transition. Now, there may
> > still be legacy code in effect today which has already had
> > CLtL1-isms taken out, but which still qualify these two packages
> > in the old style. I would be concerned about the possibility of
> > such legacy code suddenly breaking if this change were made.
>
> The implementation could have a LISP package that exports all
> the external symbols of the COMMON-LISP package (LISP could import
> them from COMMON-LISP, COMMON-LISP could inport them from LISP, both
> could import them from a third package, or some combination of
> these.) This would be compatible with even a strict reading
> of the standard.
Except that the semantics of some things have been changed incompatibly
between CLTL and ANSI CL, so CL would have to shadow some of them if the
implementation wanted to be strictly compatible with both CL and LISP.
I'm also not 100% sure that it's even possible to compatibly support
all of CL and LISP at the same time, though you can come close. There
are minor details that need resolution.
I think some things like describe or documentation (perhaps the
associated gf's) changed incompatibly between the two.
Further, I think some change to SETF may be incompatible.
Also, there are myriad small changes that involved renaming such that
CL wouldn't want all of LISP's symbols--e.g., renaming "setf methods"
to "setf expanders".
And the definitions of some things changed such that the same symbol can't
simultaneously do both. FUNCTIONP is defined quite differently in CLTL
compared to CL.
> Programs that did something like
>
> (EQ (FIND-PACKAGE "LISP") (FIND-PACKAGE "COMMON-LISP"))
>
> or perhaps this
>
> (EQ (SYMBOL-PACKAGE X) (FIND-PACKAGE "LISP"))
>
> would still break, but I imagine this is a smaller set
> of programs than those that just use LISP in the package
> prefix of symbols. The latter could be made compatible by
> making LISP the home package of the external symbols
> of COMMON-LISP.
We thought about this [latter] case in advance. CL specifically
doesn't say what the home package of symbols in the CL package is,
just to support this trick. It works for symbols shared between LISP
and CL to be homed in the LISP package; I believe CLTL might have
offered a guarantee that this would have been their home package, so
we just let that stand and take precedence.
As to the former case, we knew you could detect this but there didn't
seem any major problem in that. No legacy programs will do that.
Only newer programs will, and presumably they're just doing that to
tell if the two packages are shared--they'd better not derive any
grand truths from the equivalence, since there are likely no grand
truths to be had.
Kent M Pitman wrote:
> Except that the semantics of some things have been changed incompatibly
> between CLTL and ANSI CL, so CL would have to shadow some of them if the
> implementation wanted to be strictly compatible with both CL and LISP.
Oh, very true, but I was arguing that a person who wanted LISP to be
a nickname of the COMMON-LISP package could probably get almost the
same effect with separate packages. Customizing it as you suggest
is icing on the cake.
Paul