[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: U's use of name-spaces
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
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.