Re: U's use of name-spaces

[Nathaniel Mishkin <Mishkin@YALE.ARPA>]

    Given an export function such as the one I just posted to T-DISCUSSION,
    there should be no need for U to load anything into *SYSTEM-ENV*, nor
    should there be a need for two U environments as suggested by Meehan.
    What I would suggest is a list of symbols, say *SUGGESTED-U-EXPORTS*,
    defined in *U-ENV*.  Users who want the whole schmere could then add

        (EXPORT *SYSTEM-ENV* *U-ENV* *SUGGESTED-U-EXPORTS*)

    to their UINIT.T or

        (EXPORT *SYSTEM-ENV* *U-ENV* (*VALUE *U-ENV* '*SUGGESTED-U-EXPORTS*))

    to their INIT.T.

(1) T 2.7 has a macro called IMPORT that takes an environment to import from
    and a list of symbols.

(2) Your proposed EXPORT is both obvious and not what I want.  By module
    export control, I mean a mechanism by which a module can declare
    which parts of itself are part of its released interface and which
    parts are not (e.g. in LOOP, the LOOP macro is released, but the
    subfunctions called by the LOOP macro are not).

    Your EXPORT takes both a source and target environment.  This means
    that it is inappropriate for use in the module that defines the
    procedures (since it won't know what environment to export to).
    It is inappropriate to use EXPORT in the module that needs pieces
    of the first module -- it is not the role of a client of a module
    to know which pieces of the module he should grab into his
    environment.

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.  It's not real clear to me that this
is the right thing though.  And I certainly want some syntactic help.

We're not stupid.  The whole thing is just a little more subtle a problem
than you're implying.

                -- Nat
-------