Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!zaphod.mps.ohio-state.edu!think.com!snorkelwacker.mit.edu!bloom-beacon!dont-send-mail-to-path-lines
From: Alan@lcs.mit.EDU (Alan Bawden)
Newsgroups: comp.lang.scheme
Subject: Declarative Load and multiple environments (long)
Message-ID: <9103062113.AA00731@transit>
Date: 6 Mar 91 21:13:08 GMT
References: <13707@life.ai.mit.edu>
Sender: alan@ai.mit.edu
Organization: The Internet
Lines: 32


   Date: 5 Mar 91 16:03:02 GMT
   From: Aubrey Jaffer <jaffer@gerber.ai.mit.edu>
   ...
   Making `load' a derived expression rather than a procedure solves all
   these problems.  I will call it `include' in order to avoid name
   confusion.  The Report entry would be something like:
   ------------------------------------------------------------------------
   (include filename)                                      essential syntax

   Filename should be a string naming an existing file containing Scheme
   source code <expression1> <expression2> ....  The <expression>s are
   evaluated as though contained in a surrounding begin form
   (begin <expression1> <expression2> ...) in the lexical environment.
   ...

I think we talked about this idea a bit at Snowbird.  I believe the major
objection was that <filename> isn't an arbitrary expression.  That is,
people wanted to be able to -compute- which file to load.  (Please note:
I'm not endorsing this position, I'm just trying to remember the history.)

There may also have been concerns that a restriction like:

   If the contents of the file specified by <filename> change during
   execution of the program then the actions of include are not specified.
   ...

(which does seem necessary in order to make sense of the idea) may raise
some issues about the differences between read-time, macroexpand-time,
syntax-time, compile-time, load-time and run-time that Scheme has so far
avoided addressing.  (Again this is not my opinion, just my memory of
the history.)