Path: utzoo!news-server.csri.toronto.edu!cs.utexas.edu!usc!zaphod.mps.ohio-state.edu!wuarchive!mit-eddie!bbn.com!nic!news.cs.brandeis.edu!news!feeley
From: feeley@chaos.cs.brandeis.edu (Marc Feeley)
Newsgroups: comp.lang.scheme
Subject: Re: EVAL in Scheme
Message-ID: <FEELEY.91Mar6174651@chaos.cs.brandeis.edu>
Date: 6 Mar 91 22:46:51 GMT
References: <13781@asylum.SF.CA.US> <1991Mar5.160735.24566@rock.concert.net>
Sender: usenet@news.cs.brandeis.edu
Organization: Computer Science, Brandeis University, Waltham, MA, USA
Lines: 47
In-Reply-To: hayes@jazz.concert.net's message of 5 Mar 91 16:07:35 GMT

In hayes@jazz.concert.net's message of 5 Mar 91 16:07:35 GMT
Brian Hayes writes:

>   (let ((z 50))
>     (begin
>       (EVAL '(set! z (+ z z)))
>       (write z)))
>
>ought to cause the same trouble. We can teach our EVAL how to bind 
>variables that are created within its own scope, but it doesn't know 
>where to look for the values of variables anywhere outside that 
>scope.

Unfortunately, if you want EVAL to behave this way you are in for trouble...
EVAL should not take the current environment as its evaluation environment.
To see why, consider:

(define y 1)
(define (foo f x y) (f x))

and assume that foo is called by the form

(let ((y 50)) (foo EVAL '(+ y y) 3))

It isn't clear what should happen...  Should 100, 6 or 2 be returned?
What does 'y' refer to anyway in (+ y y)?  The 'y' in the let, the
'y' in the parameter list of foo or the global y?

If you are a fan of lexical scoping, maybe you will vote for 100.
Clearly the most recent binding to 'y' when EVAL is called is the one
where y=3, so 6 should be the right answer.  On the other hand, notice
that 'f' is called in a tail position so that the frame containing f,
x and y has been popped off the environment when f is jumped to.
Note also that the let binding frame has been popped (when foo was
called)!  From this one infers that the right answer should be
2, because 'y' refers to the global variable.  I don't think this
semantic for EVAL is particularly elegant...

My main concern with EVAL is one of efficiency.  If it is put into
Scheme without carefully thinking about all the implications then it
might well be impossible to compile efficiently.  Some Scheme
compilers generate code that outperforms C on some benchmarks and it
would be ashame to loose that.  When we think of EVAL in an
interpreter based system, it all seems trivial to implement.  Let's
think twice, it may not be that easy to implement efficiently.

Marc -- feeley@cs.brandeis.edu