[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal for EVAL
Date: Mon, 18 May 92 10:26:29 -0400
From: "Guillermo J. Rozas" <email@example.com>
Proposal for EVAL:
My recollection is that there are three different positions in the
Scheme community when it comes to EVAL, and that disagreement between
them prevents us from making progress. I will first list my
perception of the three different positions, and then suggest a
compromise, and justify the proposal with respect to how it addresses
the concerns of the three positions.
- Position "no eval": EVAL is antithetical with a Pascal-like
(compiler based, externally statically linked) implementation which
some people have or wish to see.
Although for different reasons, I speak from the "no eval" point of
(EVAL <expression> <environment specifier>) essential procedure
EVAL evaluates the expression in the environment indicated by
environment specifier. Environment specifier may be the return value
of one of the procedures NULL-ENVIRONMENT, INTERACTION-ENVIRONMENT,
SCHEME-REPORT-ENVIRONMENT, or implementation-specific extensions. No
other operations on environment specifiers are defined by this
Implementations may allow non-expression programs (i.e. definitions)
as the first argument to EVAL _only_ when the second argument is the
return value of INTERACTION-ENVIRONMENT or some implementation
extension. In other words, EVAL will never create new bindings in the
return value of NULL-ENVIRONMENT or SCHEME-REPORT-ENVIRONMENT.
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!
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.
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.
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.
Although it is neat that EVAL can be purely functional, I don't
understand the neccessity for excluding new definitions from the
NULL-ENVIRONMENT and SCHEME-REPORT-ENVIRONMENT. As a "no eval"
implementor I would only be supporting NULL-ENVIRONMENT and
SCHEME-REPORT-ENVIRONMENT with an interpreter. It is not a problem
for me to have the interpreter be able to extend an environment.
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.
Many implementations will specify the meaning for single-argument EVAL
to be the same as for EVAL with two arguments when the second argument
is the result of (INTERACTION-ENVIRONMENT).
Perhaps this, at least, can become an optional procedure in R5RS. If
two argument eval people object to using EVAL for this purpose, how
"Pascal-like" implementations can support both NULL-ENVIRONMENT and
SCHEME-REPORT-ENVIRONMENT since the environments denoted by the return
values of this procedure need not share any bindings with the current
program. A version of EVAL that supports these but not
INTERACTION-ENVIRONMENT can be written portably, but can be better
written by the implementor, since it can share code with the default
SCM still couldn't use its builtin interpreter. Code gets modified as
it is executed to memoize variable locations. If the same code were
to be EVALed in two different environments (eg., the 2 mentioned
above), the second EVAL could be referencing non-existent locations.
The concerns of the various positions:
"No eval": Supporting EVAL with NULL-ENVIRONMENT and
SCHEME-REPORT-ENVIRONMENT is harmless since they are implementable in
user code. They are convenient as a hook for implementations that
provide more features and as a way for the implementation to insert a
compiler (which a portable version could not expect/use).
Yes, but a primary use of EVAL in implementing R4RS macros is not
supported as I said previously.