Proposal for EVAL

["Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>]

   Date: Wed, 20 May 92 20:46:07 -0400
   From: "Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>
   Reply-To: jinx@martigny.ai.mit.edu

   *   I am glad that you are tackling the EVAL problem.  As one who dislikes
   *   the construct, I prefer to have it specified than to have it forever
   *   lurking beneath the surface.

   Why do you dislike it?  It is one of the strenghts of Lisp.  In few
   other languages can you compute the coefficients for a Bessel function
   and then automatically construct as good a Bessel function as anyone
   reading a set of tables could have coded, yet use it within the
   running program and be sure that there were no transcription (or
   floating-point I/O) errors.  C/Unix is only now learning the lesson
   with the ability to dynamicallly link in code.

Constructing new code character by character (C) or cons by cons
(lisp) and then dynamicallaly linking it in (or EVALing it) is not
really what we want for a First Order Metalanguage, is it?  High level
macros are a first order metalanguage which maintains a distinction
between the environments of the zeroth order scheme program and the
first order metalanguage.  My objection to EVAL is that it doesn't
maintain that distinction.  You have somewhat alleviated that
objection by mandating some environments which do observe the
separation.

The only thing you seem to saving by using EVAL in the Bessel function
example is variable lookup.  Your Bessel function example might be a
easier to code if it were possible to lexically substitue values for
variables (like #define foo 3.3 in C).  As for debugging in the
running session, that is a feature of the programming environment, not
the language.

I had previously misunderstood about macro environments.  I am sorry
for any confusion this caused.  I will start over with my comments on
your proposal.

   The positions:

   - Position "no eval": EVAL is antithetical with a Pascal-like
   (compiler based, externally statically linked) implementation which
   some people have or wish to see.

Static only linking is inconsistent with the current LOAD spec.  I
would like to see the LOAD specification be weakend to allow this
case.

   The proposal:

   (EVAL <expression> <environment specifier>)		essential procedure

   EVAL evaluates the expression in the environment indicated by
   environment specifier.  Environment specifier may be the return value
   of one of the procedures NULL-ENVIRONMENT, INTERACTION-ENVIRONMENT,
   SCHEME-REPORT-ENVIRONMENT, or implementation-specific extensions.  No
   other operations on environment specifiers are defined by this
   proposal.

   Implementations may allow non-expression programs (i.e. definitions)
   as the first argument to EVAL _only_ when the second argument is the
   return value of INTERACTION-ENVIRONMENT or some implementation
   extension.  In other words, EVAL will never create new bindings in the
   return value of NULL-ENVIRONMENT or SCHEME-REPORT-ENVIRONMENT.

   (NULL-ENVIRONMENT)					essential procedure

   This procedure returns a specifier for an environment that contains no
   variable bindings, but contains (syntactic) bindings for all the
   syntactic keywords defined in the report, and no others.

Which report?  I think this needs the same argument as
SCHEME-REPORT-ENVIRONMENT because supported syntax does change from
version to version.

   (INTERACTION-ENVIRONMENT)				procedure

   This procedure returns a specifier for an environment that contains
   implementation-defined bindings, typically a superset of those listed
   in the report.  The intent is that this procedure will return a
   specifier for the environment in which the implementation would
   evaluate expressions dynamically typed by the user.

I recommend that this instead be called PROGRAM-ENVIRONMENT.  Not all
Scheme systems are interactive.  The word Program connotes an entire
(or top level) entity or sequence and is used in section 5.2
Definitions:
	"... They are valid only at the top level of a <program> ..."

   R4RS implicitly requires some way of specifying a "vanilla" R4RS
   environment (see notes before the example in the report), thus such an
   enviornment must already be supported by compatible implementations,

Yes, it must be supported as a syntactic mode; but that doesn't mean
that such an uncorrupted environment is available simutaneously with
an INTERACTION-ENVIRONMENT where a user does things like (set! caddr 4).

Here is a version of LOAD which would be compatible with the above
eval definition:

  (load filename)				essential procedure

Filename should be a string naming an existing file containing Scheme
source code.  The load procedure reads expressions and definitions
from the file and evaluates them sequentially in PROGRAM-ENVIRONMENT.
It is unspecified whether the results of the expressions are printed.
The load procedure does not affect the values returned by
current-input-port and current-output-port.  Load returns an
unspecified value.