Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!elroy.jpl.nasa.gov!decwrl!argosy!freeman
From: freeman@argosy.UUCP (Jay R. Freeman)
Newsgroups: comp.lang.scheme
Subject: Re: EVAL in Scheme
Message-ID: <945@argosy.UUCP>
Date: 5 Mar 91 19:35:18 GMT
References: <13781@asylum.SF.CA.US> <1991Mar5.160735.24566@rock.concert.net>
Sender: news@argosy.UUCP
Reply-To: freeman@cleo.UUCP (Jay R. Freeman)
Organization: MasPar Computer Corporation, Sunnyvale, CA
Lines: 79

In article <1991Mar5.160735.24566@rock.concert.net> hayes@jazz.concert.net (Brian Hayes - Sigma Xi) writes:

> [discussion of what Scheme ought to do with the following
> expressions, and of what various implementations actually do]

>> (define x 50)
>> (EVAL '(set! x (+ x x)))
>> (write x)

>   (let ((z 50))
>     (begin
>       (EVAL '(set! z (+ z z)))
>       (write z)))

>Incidentally, I tried this experiment in one more version of Scheme: 
>Pixie Scheme, an interpreter available for a fee of $1.00 from Jay 
>Reynolds Freeman. Pixie Scheme also complains of an unbound variable, 
>but the variable is not x or z; it is EVAL. No environmental 
>ambiguities in Pixie Scheme.

    Lest anyone be misled, I should point out that Pixie Scheme runs
only on the Apple Macintosh.

    I didn't put in "eval" because I thought it was poorly named:  Since
there are several ways to do it, the name should indicate which is being
used, or should at least be sufficiently mystifying to prompt users to
look it up in the documentation.

    So Pixie Scheme has an enhancement, "e::cons-with-continuation"
that ought to result in "100" being written in either case if used
instead of "eval".  (That "e::" is *not* a package system, it is just
my convention for how I name built-in enhancements in Pixie Scheme.)

    I thought Pixie Scheme should provide some form of "eval", and
decided to punt controversial semantic issues by implementing a more
suggestively-named (for those of you familiar with the notion of an
SECD machine) instance of one popular variation; namely, the one where
evaluation is performed in the nest of environments in which the call
to "e::cons-with-continuation" was made.

    Pixie Scheme isn't quite an SECD machine internally, but
"e::cons-with-continuation" is describable in terms of one:  It
evaluates its single argument, then conses the result onto the current
contents of the "C" register, and puts the cons back into "C", all
without changing "S", "E", or "D".  Thus when execution resumes, it
finds that continuation magically contains a new form, that was
created at run-time, to be evaluated with the current environment
list; and it is the result of that latter evaluation that will be
returned as the result of the call to "e::cons-with-continuation".

    "e::cons-with-continuation" is a handful to type, but it can of
course easily hide behind "call-with-current-continuation", if
necessary.  And users may of course evaluate

    (define eval e::cons-with-continuation)

to save subsequent keystrokes.

    I thought about putting in a "two-argument eval" as well -- the
other argument being an environment -- but I was too lazy (being lazy
about evaluation is a virtue, right?) to put in other paraphernalia
necessary to make environments first-class objects.  And besides, I
was fearful that there might be additional variants on "eval" lurking
in the wings, which I would then have to provide as well, in the
interest of fairness to one and all.  (Isn't trying to be all things
to all users how PL1 got started?)

    And, based on comments in this thread, I was right; for there seem
to be "eval"s that only know about the top-level environment.  *Sigh*


                                  -- Jay "Pixie Scheme" Freeman


PS:  Does anyone know when the R4 report will be out?  Perhaps it
     will say some more about these interesting issues.  Perhaps it
     will at least indicate how to evaluate numbers ...

	  <canonical disclaimer -- I speak only for myself>