[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
SHADOW et. al
- To: common-lisp@sail.stanford.edu
- Subject: SHADOW et. al
- From: Brad Miller <miller@DOUGHNUT.CS.ROCHESTER.EDU>
- Date: Tue, 25 Aug 87 18:23 EDT
- Default-character-style: (:FIX :CONDENSED :NORMAL)
- Fonts: CPTFONTC
- Organization: University of Rochester, Department of Computer Science
- Phone: Currently: 716-275-7747 After 1 Sept. also try: 716-275-1118
- Postal-address: Computer Science Department, University of Rochester, Rochester NY 14627
- Reply-to: miller@cs.rochester.edu
- Sender: miller@cs.rochester.edu
Actually this discussion of shadow brings to mind a problem I have had with CL
packages, which deals with just what symbol you get...
Lets presume that the symbol FOO exists in 3 places, packages A B and C...
I create package D which will :USE A B C.
Which foo does it get? well, probably it will complain, and force you to
shadowing-import one of them. What I would sort of like to see (others
probably know more about the issues here than I do) is that the USE list of a
package is also the order in which the packages are searched to resolve symbol
references. Thus in the above example, a reference to FOO in D would be
resolved as A::FOO with *no complaint* about the duplicates in B and C.
For debugging purposes, there can be some special the package system uses to
complain about duplicates as in the above, what I want is a mechanism such
that there is a default, normal, behavior for such things, which allows this
duplication.
Brad Miller
------
miller@cs.rochester.edu {...[allegra|seismo]!rochester!miller}
Brad Miller
University of Rochester Computer Science Department
NOTE: Our computers will be down the first week of September to be
moved to a new home. If mail should fail, please retry. TKS!