Proposal for EVAL

["Aubrey Jaffer" <jaffer@martigny.ai.mit.edu>]

   Date: Tue, 26 May 92 08:16:24 -0400
   From: "Guillermo J. Rozas" <jinx@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.

A good macro system should be able to produce unrolled loops.  The
termination condition and the coefficients for the polynomial should
be computable in the macro environment.

   Date: Tue, 26 May 92 17:09:50 +0200
   From: tmb@idiap.ch  (Thomas M. Breuel)

   Without EVAL, how are you going to write your own, specialized
   read-eval-print loops, though? None of the macro facilities are
   powerful enough for that (and thankfully so).

No.  And they shouldn't be.  A read-eval-print loop is antithetical to
a "compile whole standalone program" system.  IEEE Scheme allows such
an implementaion but R4RS doesn't because EVAL can be implemented
using LOAD.