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:23:32 +0100 Message-ID: <87k03c2w4l.fsf@soeven.de> References: <87sfi379eb.fsf@soeven.de> <3de6bb04-890f-1104-2d9a-cd6f937c54b0@abou-samra.fr> 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="12581"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.8.11; emacs 28.2 Cc: Alexander Asteroth , guile-user@gnu.org To: Jean Abou Samra Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Wed Nov 30 18:47:02 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 1p0RAh-0002xP-TY for guile-user@m.gmane-mx.org; Wed, 30 Nov 2022 18:46:59 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p0RA8-0002Cv-Dm; Wed, 30 Nov 2022 12:46:24 -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 1p0QpL-000538-Id for guile-user@gnu.org; Wed, 30 Nov 2022 12:24:55 -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 1p0QpH-0000Sn-8W for guile-user@gnu.org; Wed, 30 Nov 2022 12:24:55 -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 2AUHOgJ4027838 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 30 Nov 2022 18:24:44 +0100 In-reply-to: <3de6bb04-890f-1104-2d9a-cd6f937c54b0@abou-samra.fr> 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:18756 Archived-At: Dear Jean, thanks for pointing that out which confirmed my interpretation of the R5RS.=20 Cheers, Alex On Mon, Nov 28 2022, 10:25:46, Jean Abou Samra wrote: > [[PGP Signed Part:Undecided]] > Le 28/11/2022 =C3=A0 09:33, Alexander Asteroth a =C3=A9crit : > > 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 =E3=80=88variable=E3=80=89s are bound to fresh locations > holding undefined values, the =E3=80=88init=E3=80=89s are evaluated in the > resulting environment (in some unspecified order), each > =E3=80=88variable=E3=80=89 is assigned to the result of the corresponding > =E3=80=88init=E3=80=89, the =E3=80=88body=E3=80=89 is evaluated in the re= sulting environmet [...] > > > As I (and others) understand=20 > > scheme@(guile-user)> (letrec ((b a)(a 7)) b) > $1 =3D 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 =3D #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? > > Interesting. R5RS says: > > =E2=80=9COne restriction on letrec is very important: it must be possible > to evaluate each without assigning or referring to the value of > any . If this restriction is violated, then it is an error. > The restriction is necessary because Scheme passes arguments by value > rather than by name. In the most common uses of letrec, all the s > are lambda expressions and the restriction is satisfied automatically.=E2= =80=9D > > Note that =E2=80=9Cit is an error=E2=80=9D does not mean that an error mu= st be raised. > This is clarified in the section =E2=80=9CError situations and unspecifie= d behavior=E2=80=9D: > > =E2=80=9CWhen speaking of an error situation, this report uses the phrase= ``an error > is signalled'' to indicate that implementations must detect and report the > error. If such wording does not appear in the discussion of an error, > then implementations are not required to detect or report the error, thou= gh > they are encouraged to do so. An error situation that implementations are > not required to detect is usually referred to simply as ``an error.''=E2= =80=9D > > Therefore, your program is buggy, and what Guile does is R5RS-conformant = because > R5RS does not define this case. > > However, R6RS differs from R5RS on this point: > > =E2=80=9CImplementation responsibilities: Implementations must de- > tect references to a =E3=80=88variable=E3=80=89 during the evaluation of = the=E3=80=88init=E3=80=89expressions > (using one particular evaluation order and order of evaluating the =E3=80= =88init=E3=80=89 > expressions).If an implementation detects such a violation of the restric= tion, > it must raise an exception with condition type &assertion.=E2=80=9D > > Therefore, according to R6RS, Guile is buggy because it should raise > an error in this case. > > Best, > Jean > > [[End of PGP Signed Part]]