Proposal for EVAL

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

   Date: Wed, 20 May 92 13:47:10 -0400
   From: "Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>

   *   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!

   Not true.  INTERACTION-ENVIRONMENT can be trivially supported by
   dialects such as MacScheme and Indiana's Scheme 84 without any support
   for what is usually called first-class environments.

Agreed.  But R4RS macros will require INTERACTION-ENVIRONMENT and
saying that "no eval" implementations don't need it then leaves those
implementations without the means to implement R4RS macros and
many any other practical uses of EVAL.

   In fact

   (define (interaction-environment)
     '*THE-INTERACTION-ENVIRONMENT*)

   (define (eval expr env)
     (case env
       ((*THE-INTERACTION-ENVIRONMENT*)
	(let ((fname (make-temporary-filename)))
	  (with-output-to-file fname (lambda () (write expr)))
	  (load fname)))
       ...))

   is a possible (although silly) implementation that uses LOAD, which is
   in the current report (I thought it had been flushed) and causes no
   problems for anyone who already supports LOAD.

R4RS does not specify in which environment LOAD forms are evaluated.
In fact there is an implementation of Scheme (I can't remember which
one) which evaluates forms from a load file in the lexical environment
of the LOAD call.  So, unless the behavior of LOAD is further
clarified, it doesn't provide a portable base for
INTERACTION-ENVIRONMENT.

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

   Only if you can introduce macros dynamically.  If you can, then you
   already have to have an evaluator that can handle this situation, and
   EVAL just gives you programmatic access to it.

SLIB's syntactic closure macro code (which to my knowledge is the only
available implementation of R4RS high level macros) does not
distinguish between systems which can introduce macros dynamically and
those which can't.  It uses one argument EVAL.  If there are other
R4RS macro implementations I would like to know if they distinguish
between dynamic and non-dynamic macro introductions.

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

   That is precisely the point of NULL-ENVIRONMENT and
   SCHEME-REPORT-ENVIRONMENT, which are essential while
   INTERACTION-ENVIRONMENT is not.

Since you are saying that INTERACTION-ENVIRONMENT is so easy to
implement I am now wondering if NULL-ENVIRONMENT and
SCHEME-REPORT-ENVIRONMENT are useful enough to include.  Could someone
give some examples of practical uses of EVAL in these environments
which could not be satisfied by INTERACTION-ENVIRONMENT?

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

   Again, you are making an invalid inference.  INTERACTION-ENVIRONMENT
   in no way demands or expects first-class environments.

Fine; but it still requires INTERACTION-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.

   You are right.  I had forgotten that LOAD had remained in the report.
   On the other hand, any implementation that supports LOAD is implicitly
   interactive, since the combination of READ, WRITE, and LOAD gives you
   a rudimentary REPL.

Now you have me worried.  Is LOAD going away?  Even as lowly a
language as C has the ability to include files.  I consider the IEEE
spec a toy without some ability to include files.  There is not much
point to vicinity if there is no LOAD.  I think that the LOAD
specification could be made weak enough to allow it act as INCLUDE
(All load files static during execution/compilation); this change
would take away its ability to implement EVAL and REPL.

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.