[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" <firstname.lastname@example.org>
Date: Wed, 20 May 92 13:47:10 -0400
From: "Guillermo J. Rozas" <email@example.com>
* 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
* 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.