[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Proposal for EVAL
Date: Wed, 20 May 92 20:46:07 -0400
From: "Guillermo J. Rozas" <firstname.lastname@example.org>
* 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.
Constructing new code character by character (C) or cons by cons
(lisp) and then dynamicallaly linking it in (or EVALing it) is not
really what we want for a First Order Metalanguage, is it? High level
macros are a first order metalanguage which maintains a distinction
between the environments of the zeroth order scheme program and the
first order metalanguage. My objection to EVAL is that it doesn't
maintain that distinction. You have somewhat alleviated that
objection by mandating some environments which do observe the
The only thing you seem to saving by using EVAL in the Bessel function
example is variable lookup. Your Bessel function example might be a
easier to code if it were possible to lexically substitue values for
variables (like #define foo 3.3 in C). As for debugging in the
running session, that is a feature of the programming environment, not
I had previously misunderstood about macro environments. I am sorry
for any confusion this caused. I will start over with my comments on
- Position "no eval": EVAL is antithetical with a Pascal-like
(compiler based, externally statically linked) implementation which
some people have or wish to see.
Static only linking is inconsistent with the current LOAD spec. I
would like to see the LOAD specification be weakend to allow this
(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.
(NULL-ENVIRONMENT) essential procedure
This procedure returns a specifier for an environment that contains no
variable bindings, but contains (syntactic) bindings for all the
syntactic keywords defined in the report, and no others.
Which report? I think this needs the same argument as
SCHEME-REPORT-ENVIRONMENT because supported syntax does change from
version to version.
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.
I recommend that this instead be called PROGRAM-ENVIRONMENT. Not all
Scheme systems are interactive. The word Program connotes an entire
(or top level) entity or sequence and is used in section 5.2
"... They are valid only at the top level of a <program> ..."
R4RS implicitly requires some way of specifying a "vanilla" R4RS
environment (see notes before the example in the report), thus such an
enviornment must already be supported by compatible implementations,
Yes, it must be supported as a syntactic mode; but that doesn't mean
that such an uncorrupted environment is available simutaneously with
an INTERACTION-ENVIRONMENT where a user does things like (set! caddr 4).
Here is a version of LOAD which would be compatible with the above
(load filename) essential procedure
Filename should be a string naming an existing file containing Scheme
source code. The load procedure reads expressions and definitions
from the file and evaluates them sequentially in PROGRAM-ENVIRONMENT.
It is unspecified whether the results of the expressions are printed.
The load procedure does not affect the values returned by
current-input-port and current-output-port. Load returns an