Re: U's use of name-spaces

[Todd Allen <Allen@YALE.ARPA>]

    Clearly, we could start a convention so that every module defines a
    list of names that are to be exported.  Then we could define a
    LOAD-AND-IMPORT function that LOADs a module into its own environment
    and then imports from that module into the environment in which the
    LOAD-AND-IMPORT call appears...

My guess is that this will remain an open question for a long time.
As far as I can tell, the T designers are not going to take a stand
on this right away, and it might be a release or two before it gets
cleared up.  In the mean time, it is up to users to establish some
conventions to be used until something more definitive is devised
by the T designers/implementors.

My suggestion is that when writing a package you create a list of
symbols called *xxx-SUGGESTED-EXPORTS* (where xxx is the name of the
module) which users can then hand to IMPORT or EXPORT.  LOAD-AND-IMPORT
is not always the right thing as it doesn't give the user the option
of picking and choosing stuff from *xxx-SUGGESTED-EXPORTS*.
    
------ From Doug Baldwin's reply ------

    ...  In my case at least it is INIT.T which loads LOOP, etc.  This
    seems a reasonable way to do things, given that I want these utilities
    in every version of T which I run. Unfortunately, since INIT.T gets
    loaded before UINIT.T the "damage" would already have been done ...
    
    This solution has ... the problem that EXPORT can only be done from
    INIT.T if one always uses U - assuming that *U-ENV* will not be an
    environment in, say, TC...

I'm glad to see that I'm not the only one with these problems.
Unfortunately the only out that I see is conditional hacking in INIT.T.
One way to find out whether you're in T, TC, or U is to test for
bindings of *TC-ENV* and *U-ENV* with the (still unreleased) macro
BOUND?.  However, as Nat suggests, we need a better way of finding
out infomation about particular T system we're running in.

Ultimately, I don't think the problem will or can be resolved by making
LOAD and REQUIRE more robust.  One must know (or, at least, have an
expectation) that something is loaded before you can even go look
for it.  The user must take some care in the design of INIT.T, but
doing it right can occur only if packages and systems (e.g., U) document
what they load and where they load it.  This whole discussion got
started because at present no such documentation (other than the
sources, and I wouldn't know where to look) exists for U.

Given some tools to grub around environments (I've built my own) and
some expectations as to what's going to happen under certain
circumstances, it is possible to devise solutions to these problems.
They're not pleasant, but they're possible.