Issue: SHADOW-ALREADY-PRESENT (version 1)

[David A. Moon <Moon@STONY-BROOK.SCRC.Symbolics.COM>]

Issue:         SHADOW-ALREADY-PRESENT

References:    CLtL p.186

Category:      CLARIFICATION

Edit history:  Moon 24 Aug 87 new issue (version 1)

Problem description:

The description of the SHADOW function can be interpreted as saying that
the function has no effect, if the symbol is already present in the
package.  This happens if the third sentence in the description ("then
nothing is done") is interpreted as applying to the entire description
rather than just to the fourth sentence.

Proposal SHADOW-ALREADY-PRESENT:WORKS:  The SHADOW function always adds
the symbol to the PACKAGE-SHADOWING-SYMBOLS list, even when the symbol is
already present in the package.

Test Case:

(make-package 'test-1)
(intern "TEST" (find-package 'test-1))
(shadow 'test-1::test (find-package 'test-1))
(assert (not (null (member 'test-1::test (package-shadowing-symbols
					   (find-package 'test-1))))))
(make-package 'test-2)
(intern "TEST" (find-package 'test-2))
(use-package 'test-2 (find-package 'test-1))	;should not error

Rationale:

Page 180 describes a name conflict problem that can occur when calling
the function USE-PACKAGE. The name conflict is between a symbol directly
present in the using package and an external symbol of the used package.
This name conflict may be resolved in favor of the symbol directly
present in the using package by making it a shadowing symbol.  For this
to work, SHADOW must add the symbol to the PACKAGE-SHADOWING-SYMBOLS list
even when it is already present in the package.

Current practice:

[I have not confirmed any of these myself except Symbolics --Moon]

Symbolics and Spice Lisp behave as proposed here.  Kyoto Common Lisp
behaves the other way.  Kolb implied, but did not state explicitly,
that Lucid Common Lisp and Xerox Common Lisp behave like KCL.  It seems
likely that we will find several implementations in each camp.

Adoption Cost:  It should be a one-line change in one function.

Cost of non-adoption: Inconsistency among implementations and lack of a
clear way to resolve the name conflict mentioned in Rationale.

Benefits: Consistency.

Conversion Cost: Technically this would be an incompatible change to
implementations that do not already behave as proposed, however it is
difficult to conceive of a user program that would require any
conversion to cope with the change.  Some users might want to remove
kludges that were only necessary to get around the misbehavior of
SHADOW.

Esthetics: The proposal would remove an unnecessary special case,
thus simplifying the language slightly.

Discussion:

The issue was raised by Dieter Kolb on the Common-Lisp mailing list.

It would be useless for SHADOW to fail to put a symbol that is already
present in the package onto the PACKAGE-SHADOWING-SYMBOLS list.  Moon
believes CLtL intended to describe what is being proposed, but
unfortunately used ambiguous language.