Package functions not powerful enough?

[Brad Miller <miller@ACORN.CS.ROCHESTER.EDU>]

Hi all.

I'm having a problem, which I think revolves around the package funtions not
really being powerful enough to "do the job" correctly. Here is an instance
of the problem, since it is best illustrated by example:

Assume the packages FOO and BAR, where FOO is on BAR's USE list. Assume that
BAR has some symbol interned and marked as external, say 'frotz. The problem
is, that given this package layout is part of some program implementation
(i.e. not meant to be seen by the user) and the program wants to intern 'frotz
as an external symbol in FOO, so any other packages that USE FOO would see
this new definition. The program "knows" about 'frotz in BAR and wants BAR to
shadow it's own definition of 'frotz over FOO's. (in fact, we can even assume
it was interned with SHADOW).

The problem is that there is no way to export the symbol from FOO without
getting an error, because of the possible conflict with the symbol in BAR.
What I would like is some capability to supply an option to EXPORT, like
"export this symbol, and for any package there is a name conflict, make the
local symbol shadow the newly exported one" or vice versa, etc., rather than
makeing the user do it via the debugger. 

The only extremely crufty solution to this problem with the existing tools
seems to be to unintern 'frotz from BAR, intern it in FOO, export it, then
SHADOW it in BAR. Since in a more realistic example the number of packages
'frotz could be in is potentially large, this doesn't seem to be the best of
plans, since each value of 'frotz must also be stored temporarily in the
interim.

To generalize the suggestion, I think that functions which have the
opportunity of creating name conflicts (as defined in section 11.5 CLtL)
should also allow the programmer to tell the system how they should be
resolved in advance. (This is an upwards compatible improvement: the
programmer need not give such "advice" and if none is given, the current
definition obtains.)

Brad Miller

PS: reply to miller@rochester.arpa, not the address in the header, it will
bounce.
------
miller@rochester.arpa
miller@ur-acorn.arpa