Re: letrec semantics

[Linus Björnstam]

Guile implements letrec using letrec*, which most schemes always did, but it 
wasn't specified due to people wanting to leave possible optimisations on the 
table. 

The order of letrec is unspecified and schemes are allowed to do whatever order 
they like. Guile uses the algorithm described in "fixing letrec(reloaded)".

-- 
  Linus Björnstam

On Mon, 28 Nov 2022, at 09:33, Alexander Asteroth wrote:
> Dear all,
>
> I know this topic has been discussed in the past. I found at least one
> discussion in 2003 in guile-user@gnu.org which in the end referred to
> even earlier discussions in comp.lang.scheme. But still I'm confused
> about this and wonder if someone could help with this or point me to a
> discussion that resolves the following issue.
>
> In R5RS it sais about letrec:
>
>>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 environmet [...]
>
> As I (and others) understand 
>
>> 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
>
> but obviously it is't. Why is b assigned to a's reference rather than
> it's value in letrec? ... and would it be a correct implementation of
> R5RS-letrec to return #nil from the letrec above?
>
> Cheers,
> Alex