[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal for EVAL
* Date: Wed, 20 May 92 16:14:17 -0400
* From: "Aubrey Jaffer" <email@example.com>
* 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 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
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.