Proposal for EVAL

["Guillermo J. Rozas" <jinx@martigny.ai.mit.edu>]

*   Date: Wed, 20 May 92 16:14:17 -0400
*   From: "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>

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

Are you sure?  I'm not.  It seems to me that SCHEME-REPORT-ENVIRONMENT
is a dead ringer for this one.  Admittedly I have not played much with
R4RS macros.

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

You are right in that the report does not specify where LOAD evaluates
the forms contained in the file, but I would think that such an
implementation is at best unpredictable and probably undesirable.

After all, LOAD is specified to be a _procedure_.  So what environment
is used in the following code:

  (apply load (list <some-file-name>))

where APPLY appears in tail-recursive position in some code.

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

They are useful because of guarantees that cannot be made about
INTERACTION-ENVIRONMENT.  Because the environments associated with
their return values are immutable, LAMBDA (or LET-SYNTAX) cannot be
re-defined in them, for example.

They are also useful because of increased portability.  A program that
only requires evaluation in null environments is considerably more
portable than a program that requires evaluation in scheme report
environments (after all, the specified version may no longer be
available), which are in turn more portable than those that depend on
INTERACTION-ENVIRONMENT, since the environment specified by the
latter's return value may contain all sorts of unexpected bindings.

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

That seems like a tautology.  It is certainly the case that having
INTERACTION-ENVIRONMENT requires INTERACTION-ENVIRONMENT.  I've
probably lost the thread of your argument here.

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

Note by the way, that NULL-ENVIRONMENT is sufficient for this example.