From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Taylan Kammer Newsgroups: gmane.lisp.guile.bugs Subject: bug#71300: [PATCH v4] doc: Document SRFI 64. Date: Mon, 30 Sep 2024 13:39:59 +0200 Message-ID: <45010bfa-8ef4-4046-9dde-540d534a1611@gmail.com> References: <20240601021743.808-1-maxim.cournoyer@gmail.com> <20240915042603.8529-1-maxim.cournoyer@gmail.com> <877cb3hnvr.fsf@wolfsden.cz> <87r096edvz.fsf@gmail.com> <20240929214340.JKjf2D00f5Amo2z01KjgPd@andre.telenet-ops.be> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="------------H1A4S0j2nCirs0bWOenKnxpG" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="2197"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla Thunderbird Cc: "71300@debbugs.gnu.org" <71300@debbugs.gnu.org>, Filip =?UTF-8?Q?=C5=81ajszczak?= To: Maxime Devos , Maxim Cournoyer , Tomas Volf <~@wolfsden.cz> Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Mon Sep 30 13:44:36 2024 Return-path: Envelope-to: guile-bugs@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 1svEpP-0000P5-QN for guile-bugs@m.gmane-mx.org; Mon, 30 Sep 2024 13:44:36 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1svEoy-000784-7o; Mon, 30 Sep 2024 07:44:08 -0400 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 1svEop-0006jK-JS for bug-guile@gnu.org; Mon, 30 Sep 2024 07:44:01 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1svEop-00061S-1z for bug-guile@gnu.org; Mon, 30 Sep 2024 07:43:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=In-Reply-To:From:References:MIME-Version:Date:To:Subject; bh=m69lt2UUbyjovwS34GAZCZkJhIlW2xcfCwDrH3Oiyfw=; b=YlBlnmxrgpVupqHOWeh5gPU7HdyppIMHqZA3u4fq8iQYsMIqIuMJftxNN1s2d9abXqAVe91x8T2XBLL+pIBO9CF3y1Ks3fra9bft1Xtboe4YdgCSHevrRXfaEMUp7rnjJYJG8ncNUX40dxDB6TiNSWUH5ZkbReaaTSh5dk0TIu23xT72AYD3TOmXWB6qayfi+6qDQYYOutDoCzKRGUsv6A4YPOjHKmyuyMC3YEp+aDTdTf9AwPmmBIYffjGxtvjRopha/jVoEZ3+hR1Lf9auRBhhpCDXv6Nstdn3/E/ZjgQvwG20V9dUrwD/+3GXc7JCnM5NkxrD/ocqVo3llYjtCw==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1svEpK-0005Tn-Ia for bug-guile@gnu.org; Mon, 30 Sep 2024 07:44:30 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Taylan Kammer Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Mon, 30 Sep 2024 11:44:29 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 71300 X-GNU-PR-Package: guile X-GNU-PR-Keywords: patch Original-Received: via spool by 71300-submit@debbugs.gnu.org id=B71300.172769664620581 (code B ref 71300); Mon, 30 Sep 2024 11:44:29 +0000 Original-Received: (at 71300) by debbugs.gnu.org; 30 Sep 2024 11:44:06 +0000 Original-Received: from localhost ([127.0.0.1]:44860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svEnz-00051c-Pw for submit@debbugs.gnu.org; Mon, 30 Sep 2024 07:43:58 -0400 Original-Received: from mail-wm1-f54.google.com ([209.85.128.54]:39872) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1svEmd-0004Yf-IR for 71300@debbugs.gnu.org; Mon, 30 Sep 2024 07:42:43 -0400 Original-Received: by mail-wm1-f54.google.com with SMTP id 5b1f17b1804b1-42cacd90ee4so6044755e9.3 for <71300@debbugs.gnu.org>; Mon, 30 Sep 2024 04:41:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1727696405; x=1728301205; darn=debbugs.gnu.org; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:from:to:cc:subject:date :message-id:reply-to; bh=m69lt2UUbyjovwS34GAZCZkJhIlW2xcfCwDrH3Oiyfw=; b=c1CrgzU0ymOSC/lT1gEkrRnI1ZsVBvHibHrt2cPp2iDAdrGCJ3H3VRx7y44fF24o0h tVtTwSWLGP1T9iLYWIOrR8XvIXuF0CtWsx1/Iul2TyvfTTZE1q9b5scc3F/V+UBe7Bsu 1zKPsbERhnbbGNS4V8hIPZzV/jPs8gKHgQWll19RBw3RfwpNNVljo5hy1gzlelryuCgq rs20Y1137VGNHs+h86AWN3yXBM5CDAWZYYaHUHACS905lHhjOIaMqIhL6c9gZVS9sCm7 QvPSkp9mNvfCTGhYx3d4Uw9cqTdOjZ+JlSl+w7IETGQXLAcegyTiL9i9lS9xxauUFpoa 0Kqg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1727696405; x=1728301205; h=in-reply-to:from:content-language:references:cc:to:subject :user-agent:mime-version:date:message-id:x-gm-message-state:from:to :cc:subject:date:message-id:reply-to; bh=m69lt2UUbyjovwS34GAZCZkJhIlW2xcfCwDrH3Oiyfw=; b=FRyaVOLaQ8eXRCE4ndHbY/pImXE1CSUZ1igBlzTavsddeecNQEnjYavDPa6peNWT6k E39nM0Dn4vJ+LocTtkDVnaFv1E4yUqD9elcagk4budKYyP/Fdkc4rqU0EaLpLm0FA5a4 4ixlu+BAbqD76B2USvguUP1kDGjXdTwF5/gQTreTBk1LHrl1ZHgEihBBA+Lcmbboc4dp XR55848aBAFAKwThRkmUC6iSjZl84DfpyuZVGoyG6xtaJZYaEFl0RLOVCUZ+tqB1trvK GLCl4fLj74zRSAa51pEAe7IIeHR/fSDMh89K+LiWbxub5lxfxZJt5wzIBNn8X8y61o7G xIMw== X-Gm-Message-State: AOJu0Yx63NA7b/6woGMvUwXzE1+nnDKypLrgtoh57Nzrr/blHdhC2fif x0CSejIwJei16PtHfb57wgIybzs6GEaPj671apnpH7HTIPGxNzOB X-Google-Smtp-Source: AGHT+IHyggL6K86Dh8kyTcDmPX5X1aJtMvRK6SZDP/u/zKmS0P8EecEMBv359HiWwM6TmYCZKI8r5A== X-Received: by 2002:a05:600c:3c9d:b0:42c:b9c8:2ba9 with SMTP id 5b1f17b1804b1-42f6daeca73mr4955445e9.6.1727696404394; Mon, 30 Sep 2024 04:40:04 -0700 (PDT) Original-Received: from ?IPV6:2003:106:8f04:c300:192e:476d:8ae3:22f2? (p200301068f04c300192e476d8ae322f2.dip0.t-ipconnect.de. [2003:106:8f04:c300:192e:476d:8ae3:22f2]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-42e969ffb11sm148747485e9.21.2024.09.30.04.40.03 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 30 Sep 2024 04:40:03 -0700 (PDT) Content-Language: en-US In-Reply-To: <20240929214340.JKjf2D00f5Amo2z01KjgPd@andre.telenet-ops.be> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-guile@gnu.org List-Id: "Bug reports for GUILE, GNU's Ubiquitous Extension Language" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Original-Sender: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.lisp.guile.bugs:10992 Archived-At: This is a multi-part message in MIME format. --------------H1A4S0j2nCirs0bWOenKnxpG Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit On 29.09.2024 21:43, Maxime Devos via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote: > >   > > >> Based on this I believe it describes the specification. > > >  > > >That's correct. It's been slightly modified in places where it said > > >things like "left to the implementation" and I was able to verify what > > >the current implementation in Guix does. > >   > > I assume Guix->Guile. > >   > > This modification of “left to the implementation” -> “what Guile does” is problematic, since it misleads readers into thinking this is the standard behaviour (it is after all named SRFI 64, not GRFI 64). > >   > > “What Guile does” is also important information to have. > >   > > To avoid this problem, when it documents a choice made by Guile, it should indicate in some way that this is Guile behaviour. > > (E.g.: “It is left to the implementation what happens when A. Guile chooses to B.”, or “It is left to the implementation what happens when A. Guile currently chooses to B, but may choose differently in future versions.”) > >   > To be fair to Guile, this is a problem caused by the reference implementation coming directly from SRFI 64. It doesn't properly follow its own specification. I believe most Scheme implementations that support SRFI-64 just use the reference implementation, just like Guile does, so one could even say: There's the "on paper" standard of SRFI 64 (the spec), and then there's the de facto standard of SRFI 64 that basically all implementations use (the reference implementation provided by the SRFI 64 author), and Guile uses the latter like every other Scheme implementation. I think the spec as written is more useful though, so I've made my implementation actually conform to it. Mainly, there's one significant difference: The test runner returned by `test-runner-simple` shouldn't use its `aux` field (and the spec explicitly claims that it doesn't), so users can use the simple test runner as a basis to extend upon, using the `aux` field to store any state that their custom extension to the runner may need to store. The `test-runner-simple` returned by the reference implementation actually *does* use the `aux` field for something internal already (name of a log file), in direct contradiction to what the spec states. > >> I think either of those is fine (albeit describing the Guile's flavor > > >> would be preferred), but is should be stated (that the behavior > > >There's not really a Guile flavor; it's more like the reference > > implementation flavor ;-).  The one in Guile is pretty stock. > >   > > Then Guile flavour is stock flavour, and stock flavour isn’t specification vanilla. From what I’ve heard, it’s not just sprinkles added to vanilla, it also has bugs (not the crunchy food kind). > One or two bugs in the upstream reference implementation were actually fixed after I had pointed them out. From a quick glance, it doesn't seem Guile ever bothered to update, though, so I guess Guile still has them. Further, on July 30, Tomas Volf sent a large number of SRFI-64 bug reports to the bug-guile mailing list. I didn't have time then, but will be responding to them now... I can see at least one clear bug he seems to have found, which my implementation doesn't seem to suffer from (simply thanks to clean coding practices). Maybe I'll find a couple more to fix, because my implementation was originally derived from the reference implementation so may still be sharing bugs with it. Some of them seem like issues with the spec instead... Anyway, I'll respond to them one by one. Thanks for raising these issues, Taylan P.S.: I've been sending HTML email using Thunderbird lately. If it messes up the formatting too much, please do complain. Some of my contacts use HTML, and I haven't yet found a way to switch back and forth quickly in Thunderbird. --------------H1A4S0j2nCirs0bWOenKnxpG Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
On 29.09.2024 21:43, Maxime Devos via Bug reports for GUILE, GNU's Ubiquitous Extension Language wrote:

 

>> Based on this I believe it describes the specification.

> 

>That's correct. It's been slightly modified in places where it said

>things like "left to the implementation" and I was able to verify what

>the current implementation in Guix does.

 

I assume Guix->Guile.

 

This modification of “left to the implementation” -> “what Guile does” is problematic, since it misleads readers into thinking this is the standard behaviour (it is after all named SRFI 64, not GRFI 64).

 

“What Guile does” is also important information to have.

 

To avoid this problem, when it documents a choice made by Guile, it should indicate in some way that this is Guile behaviour.

(E.g.: “It is left to the implementation what happens when A. Guile chooses to B.”, or “It is left to the implementation what happens when A. Guile currently chooses to B, but may choose differently in future versions.”)

 

To be fair to Guile, this is a problem caused by the reference implementation coming directly from SRFI 64. It doesn't properly follow its own specification.

I believe most Scheme implementations that support SRFI-64 just use the reference implementation, just like Guile does, so one could even say: There's the "on paper" standard of SRFI 64 (the spec), and then there's the de facto standard of SRFI 64 that basically all implementations use (the reference implementation provided by the SRFI 64 author), and Guile uses the latter like every other Scheme implementation.

I think the spec as written is more useful though, so I've made my implementation actually conform to it. Mainly, there's one significant difference: The test runner returned by `test-runner-simple` shouldn't use its `aux` field (and the spec explicitly claims that it doesn't), so users can use the simple test runner as a basis to extend upon, using the `aux` field to store any state that their custom extension to the runner may need to store. The `test-runner-simple` returned by the reference implementation actually *does* use the `aux` field for something internal already (name of a log file), in direct contradiction to what the spec states.

>> I think either of those is fine (albeit describing the Guile's flavor

>> would be preferred), but is should be stated (that the behavior

>There's not really a Guile flavor; it's more like the reference

implementation flavor ;-).  The one in Guile is pretty stock.

 

Then Guile flavour is stock flavour, and stock flavour isn’t specification vanilla. From what I’ve heard, it’s not just sprinkles added to vanilla, it also has bugs (not the crunchy food kind).

One or two bugs in the upstream reference implementation were actually fixed after I had pointed them out. From a quick glance, it doesn't seem Guile ever bothered to update, though, so I guess Guile still has them.

Further, on July 30, Tomas Volf sent a large number of SRFI-64 bug reports to the bug-guile mailing list. I didn't have time then, but will be responding to them now... I can see at least one clear bug he seems to have found, which my implementation doesn't seem to suffer from (simply thanks to clean coding practices). Maybe I'll find a couple more to fix, because my implementation was originally derived from the reference implementation so may still be sharing bugs with it. Some of them seem like issues with the spec instead... Anyway, I'll respond to them one by one.


Thanks for raising these issues,

Taylan


P.S.: I've been sending HTML email using Thunderbird lately. If it messes up the formatting too much, please do complain. Some of my contacts use HTML, and I haven't yet found a way to switch back and forth quickly in Thunderbird.

--------------H1A4S0j2nCirs0bWOenKnxpG--