Proposal for EVAL

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

*   Date: Mon, 25 May 92 22:13:36 -0400
*   From: "Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>

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

It is what _I_ want because I don't think a program is ever finished,
and I believe in incremental (dynamic) development.  I realize that
other people (probably most) disagree with me here, which is why the
proposal does not require the version that allows "mutation" of the
running program.  In other words, I don't believe in the
hierarchization into zeroth order and first order (and higher).

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

This is not true.  The "substituted" version can be CSEd by a good
compiler (therefore turning odd/even series into what programmers
would write), you save the overhead of a relatively general polynomial
evaluator (a loop traversing a data structure extracting
coefficients), and the compiler should be able to produce much more
efficient code for multiplication by constant coefficients
(particularly 0 and 1) than for generic multiplication of unknown
values.

*   I had previously misunderstood about macro environments.  I am sorry
*   for any confusion this caused.  I will start over with my comments on
*   your proposal.

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

*   Static only linking is inconsistent with the current LOAD spec.  I
*   would like to see the LOAD specification be weakend to allow this
*   case.

I would like this to be the case as well.  The EVAL proposal is a
first step in this direction, and if adopted, LOAD should be modified
to be consistent.

*   Which report?  I think this needs the same argument as
*   SCHEME-REPORT-ENVIRONMENT because supported syntax does change from
*   version to version.

True enough, but I believe that the set of special forms has changed a
lot less from report to report than other features.

We could go further and specify explicitly the set of special forms
that are available when evaluating in the result of NULL-ENVIRONMENT,
which should be pretty minimal, and could be maintained constant over
the report revisions.  In the cases that I am using something like
this for, I only need LAMBDA, LET, and conditionals, but probably
LETREC, and the syntax-binding forms (LET-SYNTAX and LETREC-SYNTAX)
should be there as well.  If a syntactic system is adopted for
inclusion in the main text of the report, we can in fact remove some
of the special forms that appear in the report (or at least demote
them), and have some confidence that the remainder would stay
constant.

Note also that since the macro system proposals have the feature that
there are no reserved words (new variable and syntax bindings shadow
syntactic keyword bindings), adding special forms to the reports does
not affect code that used to run in this context.  Only removing them
does, which is why I would like a minimal set that we can pretty much
expect to remain in place.

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

*   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
*   Definitions:
*	   "... They are valid only at the top level of a <program> ..."

Any implementation that supports this is implicitly interactive
because of the combination of I/O, and EVAL.  The user can write the
REPL:

(define (repl)
  (display "=> ")
  (let ((form (read)))
    (newline)
    (display "Value = ")
    (write (eval form (interaction-environment)))
    (repl)))

Thus the name is not inappropriate.

I certainly don't mind a change of name, but would prefer a different
one from PROGRAM-ENVIRONMENT.  In dialects with multiple environments,
programs often span many of them, and then PROGRAM-ENVIRONMENT is not
a good name because it presumes that it is unique.  I realize that
portable programs cannot span multiple environments, and that for them
the name is well defined, but I don't think we should choose a name
that implicitly assumes that the notion is universal.

Would DYNAMIC-EVALUATION-ENVIRONMENT satisfy you?  I'm not good at
choosing names.

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

Agreed, however unless the implementation is a pure R4RS
implementation (it has exactly what is specified in the report, no
less and _no more_), it must already have the implicit notion of
different startup environments.

The proposal imposes no burden on such an implementation because that
implementation could already support INTERACTION-ENVIRONMENT in
whichever way it is supporting LOAD now, and it could take the rest of
the code from the portable version, initially caching the values for
immutability.

*   Here is a version of LOAD which would be compatible with the above
*   eval definition:

*     (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
*   unspecified value.

That sounds fine with me, although I think that the bit about the
ports is overspecification (I realize that it is in the current
report).  It precludes implementations from having a
set-current-input-port! procedure that can be invoked usefully from
loaded files.