[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: eval questions
| Date: Tue, 27 Jan 1998 12:33:15 -0500 (EST)
| From: "R. Kent Dybvig" <dyb@cs.indiana.edu>
| Subject: eval questions
|
| I have a few questions about this:
|
| 1. May/must the environment contain bindings for variables that name
| optional procedures, such as transcript-on and sin? If not, what exactly
| is the set of bindings specified in the corresponding report? My guess
| is that the intent is for the environment to contain all required bindings
| and some subset of the optional bindings, but the word "exact" here
| is inappropriate.
You are right that the word "exact" is inappropriate. The intent was
to include all the required and a (possibly empty) subset of the
optional variables appearing in the report. The intent was that a
code generator generating code for report N would be able to run its
code in the corresponding environment.
| 2a. Can the environment contain bindings for identifiers not present in
| the report? The word "exact" notwithstanding, I believe that the answer
| to this question is yes. Say the environment contains a binding for the
| variable foo to a location containing the value 3. Since it is an error
| to reference an unbound variable, but an implementation is not required
| to signal the error, we can simply claim that foo is not bound. So what
| if erroneous references to foo happen to return 3? So what if erroneous
| references to foo return 4 after an erroneous assignment of foo to 4?
My intent when I wrote the proposal was that it should NOT be allowed.
I agree with you that the issue can be mooted when thinking about past
and current reports which have only indirect ways of finding out
whether a variable is bound and/or assigned. However, if the
mechanism is to be uniformly useful for future reports that may
contain error handling, the behavior would be different whether such a
variable was bound/assigned or not.
The issue becomes more complicated if we do things such as
(condition-case
(eval 'foo (scheme-report-environment 3))
((unbound-variable) ...)
((unassigned-variable) ...)
(else
...))
where the code evaluated in the report's environment need not know
about error handling but the surrounding code does.
I realize that we could define the problem away, but again, I think
that it is more natural (and was my intent) to disallow additional
unexpected bindings.
| 2b. If the answer to Question 2a is indeed yes, what does the restriction
| that eval is not allowed to create new bindings in the environment
| associated with scheme-report-environment mean?
The restriction was intended to make the environment handle represent an
immutable environment.
| 2c. Again, if the answer to Question 2a is yes, can I not simply define
| scheme-report-environment as follows:
|
| (define scheme-report-environment
| (lambda (v)
| (if (eq? v 5)
| (interaction-environment)
| (error ...))))
|
| assuming that the environment specified by the value returned by
| interaction-environment contains a superset of the bindings listed
| in R5RS?
Again, this would violate the intent of the original proposal.
| 3. Suppose an implementation conforms to R5RS but supports version=3.
| Must (eval '(eqv? "" "") 3) return #t, as required in R3RS? Must
| (eval '(if '() 'yes 'no) 3) return no, as required in R3RS? Looking
| forward, if we alter the semantics of some required procedure for R6RS,
| e.g., eval(!), must a conforming R6RS implementation support the R5RS
| semantics if it allows version=5?
Absolutely. Otherwise it would not be an R3RS environment.
| I have similar questions about null-environment.
The intent of null-environment was to have only a minimal set of
special forms and no variable bindings at all. Its usefulness comes
from expressions such as
((eval '(lambda (+ - * =)
(letrec ((fact
(lambda (n)
(if (= n 0)
1
(* n (fact (- n 1)))))))
fact))
(null-environment))
my-+ my-- my-* my-=)
|
| I apologize for bringing these questions up at the last minute, but I
| am just now getting around to trying to implement this feature.
Better late than never.