LOAD

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

I would like to either remove LOAD from the report or change the way in
which it is presented.

Reasons:

(a) A LOAD procedure is equipotent with EVAL, and EVAL isn't documented.
The same reasons that applied to kick out EVAL apply here.

(b) It seems to me a perfectly reasonable idea to create Scheme systems
that don't have a LOAD procedure.  I can imagine at least two completely
different kinds of implementations in which LOAD wouldn't make sense.
One kind of implementation would be in the style of most implementations
of PASCAL, FORTRAN, etc., where one runs programs by configuring entire
environments at once.  This avoids all the semantic stickiness of LOAD
and EVAL by making configuration a meta-issue.  Second, at the opposite
extreme, in an Interlisp-like implementation where one actually edits
"in core", and files don't generally come into play, LOAD is pretty
meaningless.

(c) It seems to me that LOAD is a user interface/programming environment
issue.  We don't talk about read-eval-print loops, or entering or
exiting scheme, or logging in, or editing files; how is this different?

Alternative solutions:

(1) Omit it entirely without saying anything.

(2) Mention somewhere (e.g. in the introduction) that Scheme is
"usually" an interactive language with a read-eval-print loop and
support for things like interactive debugging and dynamic program
loading.

(3) Reclassify LOAD as being part of the syntax of a file.  I.e., like
DEFINE, it can only occur at top level in a file.

(4) Leave it alone, but put it in a "user interface" section along with
TRANSCRIPT-ON and TRANSCRIPT-OFF (and maybe TRACE, DEBUG, and EDIT?),
instead of classifying it as an input procedure.  Make a disclaimer that
these things are only guaranteed to work "at top level" (whatever that
is).

(5) Some combination of (3) and (4) [allow it both in files and at
command loops].


Feedback solicited.

-Jonathan

-----

KMP: please send a message making a case for a (LOAD-SILENTLY x).