[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Interpretation of shadowing
- To: "Dieter Kolb" <unido!ztivax!kolb@seismo.CSS.GOV>
- Subject: Re: Interpretation of shadowing
- From: <samalone@ATHENA.MIT.EDU>
- Date: Mon, 24 Aug 87 10:51:44 EDT
- Cc: email@example.com
- In-reply-to: Your message of Mon, 24 Aug 87 14:50:37 -0100. <8708241350.AA23968@ztivax.uucp>
CLtL describes in section 11.5, page 180 a name conflict
problem by applying 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.
However, CLtL gives no advice how that should be done.
In our understanding the function shadow should be used to
resolve this name conflict.
However the function shadow has no effect, if the symbol is
already present in the package (CLtL, section 11.7). So,
following CLtL, this could not be the solution...
I understand your confusion. I believe that the problem is due to an
ambiguity in the definition of SHADOW given in CLtL. (Someone on the cleanup
committee should correct me if I'm wrong.) Unfortunately, many Common Lisp
implementers have taken the wrong interpretation of this section of the
manual, and so propagated the confusion on to their users.
You are correct that SHADOW should be used to resolve the name conflict you
described. Interpreted correctly, CLtL describes a SHADOW function that _is_
capable of resolving the name conflict.
When CLtL says that "If such a symbol is present in this package, nothing is
done", this is intended to contrast only with the following sentence, which
says "Otherwise, a new symbol is created with this print name..." The next
sentence that says "The symbol is also placed on the shadowing-symbols list of
package" applies regardless of whether such a symbol is present in this
package or not.
Given this interpretation, SHADOW has an effect whether the symbol is already
present in the package or not (unless it is already a shadowing symbol), and
so is the correct way to resolve the name conflict you described. From the
descriptions you provided, it sounds like the SPICE LISP implementers did the
--Stuart A. Malone