From: Alexander Asteroth <alexander.asteroth@soeven.de>
To: Taylan Kammer <taylan.kammer@gmail.com>
Cc: Alexander Asteroth <alex@soeven.de>, guile-user@gnu.org
Subject: Re: letrec semantics
Date: Wed, 30 Nov 2022 18:24:48 +0100 [thread overview]
Message-ID: <87fse02vz5.fsf@soeven.de> (raw)
In-Reply-To: <8f5d8b22-f073-272f-004b-d18a14f7f166@gmail.com>
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.
next prev parent reply other threads:[~2022-11-30 17:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-28 8:33 letrec semantics Alexander Asteroth
2022-11-28 9:25 ` Jean Abou Samra
2022-11-30 17:23 ` Alexander Asteroth
2022-11-28 14:07 ` Taylan Kammer
2022-11-30 17:24 ` Alexander Asteroth [this message]
2022-12-01 9:30 ` Linus Björnstam
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/guile/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87fse02vz5.fsf@soeven.de \
--to=alexander.asteroth@soeven.de \
--cc=alex@soeven.de \
--cc=guile-user@gnu.org \
--cc=taylan.kammer@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).