Re: letrec semantics

[Alexander Asteroth]

Dear Taylan,

thanks for pointing me to the use of letrec* in this case. The case
though was meant as an example to illustrate the problem. I'm currently
implementing an R5RS interpreter and was unsure if I can handle letrec
as illustrated below in the second case or if I need to implement it as
guile does.

Cheers,
Alex

On Mon, Nov 28 2022, 15:07:39, Taylan Kammer <taylan.kammer@gmail.com> wrote:

> On 28.11.2022 09:33, Alexander Asteroth wrote:
>> 
>>> scheme@(guile-user)> (letrec ((b a)(a 7)) b)
>>> $1 = 7
>> 
>> should be equivalent (of course in a new scope) to:
>> 
>>> scheme@(guile-user)> (define b #nil)
>>> scheme@(guile-user)> (define a #nil)
>>> scheme@(guile-user)> (set! b a)
>>> scheme@(guile-user)> (set! a 7)
>>> scheme@(guile-user)> b
>>> $2 = #nil
>> 
>
> Hi Alex,
>
> The only reason the first example returns 7 is because Guile *happens* to
> bind a to 7 before it binds b to the value of a.  The code could have as
> well returned another value (IIRC Guile uses #<unspecified>) had Guile
> decided to evaluate the arms of the letrec in a different order.
>
> As per the part of the standard you quoted:
>
>> the 〈init〉s are evaluated [...] (in some unspecified order)
>
> That's what the "unspecified order" in the parentheses is referring to.
>
> On the other hand, in your second code example, there's a strict order
> in which the various expressions will be evaluated.  In the moment you
> type in (set! b a), the value of a has not yet been changed to 7.
>
> If you want to use letrec but with a specific order of evaluation of the
> arms, then you can use the letrec* variant:
>
>> (letrec* ((a 7) (b a)) b)
>> $1 = 7
>
> This will definitely work, without relying on chance or an implementation
> detail of Guile.