Proposal for EVAL

["Chris Hanson" <cph@martigny.ai.mit.edu>]

   Date: Wed, 20 May 92 16:14:17 -0400
   From: "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.

I don't understand why you keep saying this.  You have repeated this
statement several times without any justification to convince me that
it is so.

The implementation of R4RS macros that I developed and distributed
does not require anything at all like INTERACTION-ENVIRONMENT.  In
fact, it supplies its own EVAL, which deliberately disallows
top-level definitions, because the R4RS specification says that it is
an error for an macro expander expression to perform them.

   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.

There are two other macro implementations, one for each of the other
two low-level macro proposals.  One of them is available for ftp from
altdorf, the other from somewhere at Indiana U.; I have a copy of the
latter if you need one.  I don't know if they distinguish these
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?

I believe that SCHEME-REPORT-ENVIRONMENT is useful, since it is a
"pure" portable environment for people who want their programs to
work the same way across implementations.  Since the report mandates
the existence of this environment anyway, it does no harm to supply it
in this form.

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

As far as I know, no one has proposed removing LOAD from the report.