Re: load

[Jonathan Rees <Rees@YALE.ARPA>]

    Date:    Wed, 4 Apr 84 08:34:25 EST
    From:    Stanley Letovsky <Letovsky>

    Excuse me. I was so excited the other day to find that BIND binds locations
    and not just variables that I was over-using it. What I had in mind for
    load should have been expressed as (embedded in a file)
    
                (SET *SAVED-ENV* (LOAD-ENV))
                (SET (LOAD-ENV) *OTHER-ENV*)
                -definitions-
                (SET (LOAD-ENV)  *SAVED-ENV*)
    
     The change to load is simple, and makes a file look more like a repl.
    Instead of passing its ENV argument down to its subfunctions as a parameter,
    let LOAD bind (LOAD-ENV) to the value of that argument, and have the
    subfunctions get it from the switch when they need it.

[To sum up our discussion of earlier today:]

I like to think of files as having some declarative meaning.  Therefore
they should be as little like REPL's as possible.  If one top-level
form can change the meaning of subsequent forms, then there is no
way to extract meaning from the file without executing it, and that's
not good.

The suggestion also violates the desirable property that a sequence
of forms A B C in a file may be replaced by a single form (BLOCK A
B C) without altering the semantics of the file.

However, I can see the motivation for what you suggest.  File boundaries
are loaded with too much meaning in T, and in Cedar Mesa, and in every
Lisp dialect I'm familiar with.  There shouldn't exist things you
can do with files, such as have things evaluated in different
environments, that you can't also do in some other way.  This situation
(which relates to the problem of module interconnection) should be
remedied somehow, but it's a tarpit.  Another item on the list of
things to do.