Proposal for EVAL

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

   Date: Mon, 18 May 92 10:26:29 -0400
   From: "Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>
   Reply-To: jinx@martigny.ai.mit.edu

   Proposal for EVAL:

   My recollection is that there are three different positions in the
   Scheme community when it comes to EVAL, and that disagreement between
   them prevents us from making progress.  I will first list my
   perception of the three different positions, and then suggest a
   compromise, and justify the proposal with respect to how it addresses
   the concerns of the three positions.

   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.

Although for different reasons, I speak from the "no eval" point of
view.

   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.

This constraint is so stringent that one of the most important
uses of EVAL, namely implementing R4RS macros, will only be possible
with first-class environments!

The first problem here is the decision that macros share the same
"binding space" with regular programs.  This gives Scheme a self
referential ability that neccessitates use of INTERACTION-ENVIRONMENT.

 Note: It is actually this property that causes my dislike of EVAL.  I
 have no problem with an EVAL which can not modify the environment of
 the executing program.

The second problem is that macro implementations define new symbols
using EVAL (correct me if I am wrong on this).  This again requires
use of INTERACTION-ENVIRONMENT and hence first-class environments.

Although it is neat that EVAL can be purely functional, I don't
understand the neccessity for excluding new definitions from the
NULL-ENVIRONMENT and SCHEME-REPORT-ENVIRONMENT.  As a "no eval"
implementor I would only be supporting NULL-ENVIRONMENT and
SCHEME-REPORT-ENVIRONMENT with an interpreter.  It is not a problem
for me to have the interpreter be able to extend an environment.

   (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.

Since not all implementations are interactive, I don't think this is
the proper criterion for describing this environment.  How about the
environment into which scheme code is LOADed.  This brings up another
point.  LOAD is intimately connected to EVAL.  I think you may need to
refine the definition of LOAD as well.

		   RATIONALE:

   Many implementations will specify the meaning for single-argument EVAL
   to be the same as for EVAL with two arguments when the second argument
   is the result of (INTERACTION-ENVIRONMENT).

Perhaps this, at least, can become an optional procedure in R5RS.  If
two argument eval people object to using EVAL for this purpose, how
about EVAL1.

   "Pascal-like" implementations can support both NULL-ENVIRONMENT and
   SCHEME-REPORT-ENVIRONMENT since the environments denoted by the return
   values of this procedure need not share any bindings with the current
   program.  A version of EVAL that supports these but not
   INTERACTION-ENVIRONMENT can be written portably, but can be better
   written by the implementor, since it can share code with the default
   evaluator/compiler.

SCM still couldn't use its builtin interpreter.  Code gets modified as
it is executed to memoize variable locations.  If the same code were
to be EVALed in two different environments (eg., the 2 mentioned
above), the second EVAL could be referencing non-existent locations.

   The concerns of the various positions:

   "No eval": Supporting EVAL with NULL-ENVIRONMENT and
   SCHEME-REPORT-ENVIRONMENT is harmless since they are implementable in
   user code.  They are convenient as a hook for implementations that
   provide more features and as a way for the implementation to insert a
   compiler (which a portable version could not expect/use).

Yes, but a primary use of EVAL in implementing R4RS macros is not
supported as I said previously.