[r6rs-discuss] [Formal] preposterous mustard
 
On Feb 5, 2007, at 7:18 AM, Michael Sperber wrote:
>
> William D Clinger <will_at_ccs.neu.edu> writes:
>
>> Page 35, specification of letrec*:
>>
>>   One restriction on letrec* is very important: it must be possible
>>   to evaluate each init without assigning or referring to the value
>>   the corresponding variable or the variable of any of the bindings
>>   that follow it in bindings.
>>
>> It is undecidable whether there exists an order of evaluation
>> for the right hand sides of the bindings that can avoid such
>> assignments or references.  The R6RS should permit implementations
>> to evaluate expressions in some particular order, without
>> requiring implementations to perform an exhaustive search of
>> the order-of-evaluation space at run time, complete with the
>> overhead necessary to undo any side effects that are performed
>> by evaluations that run afoul of the restriction.
>
> I see your point for `letrec', which you describe separately.
> However, for `letrec*' order of evaluation is specified.  So the
> comment about "exhaustive search of the order-of-evaluation space"
> doesn't seem to apply.  Am I missing something?
The order of evaluation of the bindings themselves is specified by  
letrec*.
But the order of evaluation of the argument expressions in an  
invocation subexpression on the right-hand-side of a particular  
binding is not specified.
For example, an implementation that uniformly evaluates invocation  
arguments in left-to-right order might end up having no assignment or  
reference to successor variables of the letrec* expression, but  
another implementation that uniformly evaluates invocation arguments  
in right-to-left order might have an assignment or reference to  
successor variables of the letrec* expression.
The following expression might serve as an illustration of the  
problem: (letrec* ((x 3) (y (foocall (begin (set! x 4) 5) (if (= x 4)  
6 z))) (z 7)) y)
-Felix
Received on Mon Feb 05 2007 - 12:31:24 UTC
This archive was generated by hypermail 2.3.0
: Wed Oct 23 2024 - 09:15:01 UTC