REQUIRE and friends

[Jonathan A Rees <JAR@MIT-MC.ARPA>]

    Date: 6 Dec 85 15:13:04 EST (Fri)
    From: <young%YALE-RING at YALE.ARPA>

    [I realize that REQUIRE isn't released.]

    While trying to load T3 into ALFL, ...

Wow!  I want that version of ALFL.

    I got the following error message:

            ** Error: illegal to create new bindings in this environment
              (ENV-LOOKUP ... %LOOP:EXPAND-MACRO #t #t)

    This is apparently because I used REQUIRE within a BIND form - thus 
    not at top level.  

    Why can't I use REQUIRE at any other than top level?

One day I was making some changes to the implementation of environments
and felt like removing various random features like this.  I think I
justified this by saying I didn't want people trying to imagine that T's
DEFINE worked like MIT Scheme's DEFINE, and in fact I wanted to leave
open the option of changing this at some point, so I added some error
checks to *DEFINE as a first step towards liberation.  I think there
were other considerations, but I can't recall now.  This particular
error can't possibly happen unless somehow you have your hands on one of
T's "immutable environments," which you can't get unless you're running
in a debugger B breakpoint or you're using undocumented things like
REQUIRE and THE-ENVIRONMENT.

    Perhaps REQUIRE should take an optional environment parameter?

REQUIRE isn't released because I never convinced myself it was a
reasonable thing to have.  It was inspired by the USING/ENVIRON feature
of Cambridge Algol68, which has the semantics (although not the
implementation) of textual inclusion.  REQUIRE also happened to have the
additional feature of demand loading of a named modules (this is what
Common Lisp's REQUIRE was, later).  Actually these are two (or three)
different features which should have been implemented orthogonally;
*REQUIRE sort of does the load-on-demand part.  But I never got around
to working on it.  Part of it was that I could never figure out a good
operating-system- and site-independent way to name modules.  You would
like to write modules which use and demand-load each other, but not have
to change your source code when going from one machine to another.  You
would like each program to potentially have its own space of module
names, to avoid collisions.  (Common Lisp really lost on this count; the
space of module (and package) names is flat.)  *REQUIRE and LOAD
maintain an environment-specific list of loaded modules, but I don't
think that's quite the right thing.

So eventually only the lower-level LOAD got put into the manual, and
rather than document REQUIRE or *REQUIRE, we just waited hoping that
once locales really worked, a good proposal for a module system would
fall into our laps.  It never did.  John Lamping worked on one during
summer of '84, but than I stopped doing T development, and I don't think
anyone else has picked up on it.

    Should I just use *REQUIRE instead?  

Do whatever you want.  *REQUIRE probably won't go away until there's a
better way to deal with demand loading.

Why don't you design & propose a module system for T?  At the very least
we could argue about the problem better if there was something solid to
critique.  All the basic mechanism is there: environment creation and
access, loading files into mutable environments, tables, and so on, so
there's plenty of opportunity for experimentation.  You clearly don't
want LOOP to be loaded into the same environment that your program is
running in; but then somehow the system has to decide what environment
LOOP should be loaded into, how to let it provide things for export, how
to get the things it exports, and so on.  There's a modest amount of
engineering required.  T's mutable environments are very general, and
it's just a matter of deciding on a discipline for their use.  Some
protocol must be adopted as standard if we're going to have an
environment where users can share software with each other.