[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Chicken-hackers] What happened to -strict-letrecs?
|
From: |
Alex Shinn |
|
Subject: |
Re: [Chicken-hackers] What happened to -strict-letrecs? |
|
Date: |
Sun, 10 Feb 2008 11:36:08 +0900 |
|
User-agent: |
Gnus/5.11 (Gnus v5.11) Emacs/22.1.50 (darwin) |
>>>>> "John" == John Cowan <address@hidden> writes:
John> Alex Shinn scripsit:
>> The current letrec behavior is a perfectly compliant
>> interpretation of R5RS. There is another compliant
>> interpretation which would signal an error in some cases.
John> Here are the relevant bits of code from SISC's
John> r5rs_pitfall.scm:
John> ;;Credits to Al Petrofsky ;; In thread: ;; defines in letrec
John> body ;;
John>
http://groups.google.com/groups?selm=87bsoq0wfk.fsf%40app.dial.idiom.com
In that message he's talking about the following description
of LETREC semantics from R5RS:
_Semantics:_ The <variable>s are bound to fresh
locations holding undefined values, the <init>s are
evaluated in the resulting environment (in some
unspecified order), each <variable> is assigned to the
result of the corresponding <init>, the <body> is
evaluated in the resulting environment, and the
value(s) of the last expression in <body> is(are)
returned. Each binding of a <variable> has the entire
`letrec' expression as its region, making it possible
to define mutually recursive procedures.
The call/cc trick just makes the <init>s return *twice*,
mutating the variables in between and thus exposing the fact
that some implementations of LETREC don't evaluate all of
the <init>s before performing all of the assignments.
The question is, what does it mean that "the <init>s are
evaluated?" If you're just referring to the first time they
return, then we're OK - the second time happens after the
LETREC assignments have happened. If you infer from the
spec that "evaluated" means both times (i.e. their entire
dynamic extent), then you've broken the next rule of LETREC:
One restriction on `letrec' is very important: it must
be possible to evaluate each <init> without assigning
or referring to the value of any <variable>. If this
restriction is violated, then it is an error.
You're assigning to the variables while the <init>s are
being evaluated, which is an error, which is the
programmer's fault, not the implementer's.
--
Alex