From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Alexander Asteroth Newsgroups: gmane.lisp.guile.user Subject: Re: letrec semantics Date: Wed, 30 Nov 2022 18:24:48 +0100 Message-ID: <87fse02vz5.fsf@soeven.de> References: <87sfi379eb.fsf@soeven.de> <8f5d8b22-f073-272f-004b-d18a14f7f166@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12404"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.11; emacs 28.2 Cc: Alexander Asteroth , guile-user@gnu.org To: Taylan Kammer Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Nov 30 18:47:01 2022 Return-path: Envelope-to: guile-user@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1p0RAg-0002vi-VE for guile-user@m.gmane-mx.org; Wed, 30 Nov 2022 18:46:58 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0RA7-0002Cq-4N; Wed, 30 Nov 2022 12:46:23 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0QsP-0005MM-7P for guile-user@gnu.org; Wed, 30 Nov 2022 12:28:05 -0500 Original-Received: from sv-2s11.infcs.de ([194.95.66.48] helo=ux-2s-mailproxy.inf.h-brs.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p0QsL-0001Ke-KV for guile-user@gnu.org; Wed, 30 Nov 2022 12:28:03 -0500 Original-Received: from gyps.h-brs.de (i5C751444.versanet.de [92.117.20.68]) (authenticated bits=0) by ux-2s-mailproxy.inf.h-brs.de (8.15.2/8.15.2/Debian-8ska0) with ESMTPSA id 2AUHRwgF028009 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2022 18:27:58 +0100 In-reply-to: <8f5d8b22-f073-272f-004b-d18a14f7f166@gmail.com> X-Auth: by SMTP AUTH @ ux-2s11 X-MIMEDefang-Info-ge: Gescannt in Inf@FH-BRS, Regeln s. MiniFAQ E-Mail/Mailscanner X-Scanned-By: MIMEDefang @ FB02 @ H-BRS Received-SPF: none client-ip=194.95.66.48; envelope-from=alexander.asteroth@soeven.de; helo=ux-2s-mailproxy.inf.h-brs.de X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Mailman-Approved-At: Wed, 30 Nov 2022 12:46:20 -0500 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.user:18755 Archived-At: 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 wrot= e: > On 28.11.2022 09:33, Alexander Asteroth wrote: >>=20 >>> scheme@(guile-user)> (letrec ((b a)(a 7)) b) >>> $1 =3D 7 >>=20 >> should be equivalent (of course in a new scope) to: >>=20 >>> 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 =3D #nil >>=20 > > 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 #) had Guile > decided to evaluate the arms of the letrec in a different order. > > As per the part of the standard you quoted: > >> the =E3=80=88init=E3=80=89s are evaluated [...] (in some unspecified ord= er) > > 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 =3D 7 > > This will definitely work, without relying on chance or an implementation > detail of Guile.