Re: Defining symbols in *SYSTEM-ENV*

[Jonathan Rees <Rees@YALE.ARPA>]

    From: johnson@Yale-MBUILD
    
    t2.7.doc says that it is poor taste to bind symbols in *STANDARD-ENV*.
    However, U DOES bind symbols in *SYSTEM-ENV*; furthermore there is
    a comment (in usenv0.t) saying that the Tau implementers say that this
    is a proper thing to do.  Could I have a clarification on this?

Note that *SYSTEM-ENV* has been renamed to be *STANDARD-ENV*.  If
you changed or added bindings to *STANDARD-ENV* it would no longer
be a standard environment, and this might break some programs.  I
admit there's no other way right now to make something be really global.
But the desirability of this is not clear; on the Lisp Machine, for
example, the GLOBAL: package is locked (in fact, any package which
has subpackages is locked) and I think that people never add bindings
to it.  However, one reason it's easier to get by without that is
that their notation for non-local references is more concise (FOO:BAR
instead of (*VALUE *FOO-ENV* 'BAR)).  We have been playing with the
idea of introducing a more concise reader syntax for (*VALUE ...),
and that might help.

One thing I've considered is interposing an environment in between
the standard environment and the scratch environment in which a user
could put bindings which want to be visible to all his/her modules.
Again, people get by without this on the Lisp Machine, and the question of
where user A's "globals" end and user B's begin isn't clear.
Explicit IMPORT's and EXPORT's would be better, if there were
reasonable support for modules in T.  I hate to keep repeating "we're
working on it" but it's true.

    Incidentally, there is a bug with doing this in compiled code; I end
    up with symbols which are defined in *SYSTEM-ENV* but not in *SCRATCH-ENV*.

This is a bug in the way compiled code refers to free variables; if
a free variable is referenced but not bound at load time, then it
becomes "bound to unbound" in the inner environment (Lisp Machine
packages have the same bug, but unfixably so), so an outer definition
will never be seen.  This falls in the category of
LOCALE-loses-with-forward-references bug.  This will be fixed sometime.