GNU logs - #75439, boring messages

Message sent to bug-guile@HIDDEN:

Subject: bug#75439: Behaviour of equal? on R6RS records is wrong by the spec, also the Wrong Thing in general
Resent-From: Daphne Preston-Kendal <dpk@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-guile@HIDDEN
Resent-Date: Wed, 08 Jan 2025 17:23:01 +0000
Resent-Message-ID: <handler.75439.B.173635697125172 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 75439 <at> debbugs.gnu.org
Feedback-ID: ibc314252:Fastmail
From: Daphne Preston-Kendal <dpk@HIDDEN>
Content-Type: text/plain;
	charset=utf-8
Content-Transfer-Encoding: quoted-printable
Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\))
Message-Id: <F88A5CD6-524A-4663-9425-0BAF84997159@HIDDEN>
Date: Wed, 8 Jan 2025 18:22:24 +0100
Received-SPF: pass client-ip=103.168.172.154; envelope-from=dpk@HIDDEN;
 helo=fhigh-a3-smtp.messagingengine.com
X-Spam_score_int: -27
X-Spam_score: -2.8
X-Spam_bar: --
X-Spam_report: (-2.8 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_VALIDITY_RPBL_BLOCKED=0.001,
 RCVD_IN_VALIDITY_SAFE_BLOCKED=0.001, SPF_HELO_PASS=-0.001,
 SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: 1.4 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview: Guile always compares record instances by their field
 structure
 when equal? is used, including for instances of record types defined by R6RS
 define-record-type, as demonstrated here: $ guile --r6rs scheme@(guile-user)>
 (import (rnrs records syntactic)) scheme@(guile-user)> (define-record-type
 foo (fields a b)) scheme@(guile-user)> (define x (make-foo 1 2))
 scheme@(guile-user)> (de [...] 
 Content analysis details:   (1.4 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 -0.0 RCVD_IN_DNSWL_NONE     RBL: Sender listed at https://www.dnswl.org/,
 no trust [2001:470:142:0:0:0:0:17 listed in] [list.dnswl.org]
 -0.0 SPF_HELO_PASS          SPF: HELO matches SPF record
 0.7 SPF_NEUTRAL            SPF: sender does not match SPF record (neutral)
 0.1 URIBL_SBL_A Contains URL's A record listed in the Spamhaus SBL
 blocklist [URIs: cisco.github.io]
 0.6 URIBL_SBL Contains an URL's NS IP listed in the Spamhaus SBL
 blocklist [URIs: cisco.github.io]
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.4 (/)

Guile always compares record instances by their field structure when =
equal? is used, including for instances of record types defined by R6RS =
define-record-type, as demonstrated here:

$ guile --r6rs
scheme@(guile-user)> (import (rnrs records syntactic))
scheme@(guile-user)> (define-record-type foo (fields a b))
scheme@(guile-user)> (define x (make-foo 1 2))
scheme@(guile-user)> (define y (make-foo 1 2))
scheme@(guile-user)> (equal? x y)
$1 =3D #t

There are two parts to this bug report:
1. Objectively, this is not compatible with the R6RS, which clearly =
requires something else here
2. Subjectively, this is the Wrong Thing for all record types and should =
more widely be changed to match what the R6RS (and other record type =
SRFIs including SRFI 99) requires

According to the R6RS,
> The equal? predicate treats pairs and vectors as nodes with outgoing =
edges, uses string=3D? to compare strings, uses bytevector=3D? to =
compare bytevectors (see library chapter on =E2=80=9CBytevectors=E2=80=9D)=
, and uses eqv? to compare other nodes.

So records =E2=80=93 at least those whose types were defined by R6RS =
define-record-type =E2=80=93 should be compared by eqv?, which on =
records means by pointer identity.
(R7RS small =E2=80=93 for some unknown reason =E2=80=93 left equal? =
unspecified on records. SRFI 9 is completely silent about record =
identity. So technically Guile is conforming, for those specs. But e.g. =
SRFI 99 is in agreement with R6RS on this issue.)

The behaviour appears to be connected to a Guile-specific notion of =
record type =E2=80=98opacity=E2=80=99 which has nothing to do with the =
R6RS sense of =E2=80=98opacity=E2=80=99. (Even record types which are =
not declared to be =E2=80=98opaque=E2=80=99 in their R6RS-style type =
definition should use eqv? for equal?.)

Also, in general, comparing records by their field structure in equal? =
is a bad idea.
When record types are used to implement data structures, those data =
structures might have different internal structure but externally =
represent collections which are equivalent in the sense programmers =
expect of =E2=80=98equal?=E2=80=99 =E2=80=93 even if readtables or =
similar are used to give them lexical syntax and make them datums.

An example would be a functional set implemented as a binary tree. A =
binary tree which contains two elements might have two different =
structures, namely it could either be left-balanced or right-balanced, =
as follows:

  [2]
  / \
[1] [ ]

  [1]
  / \
[ ] [2]

(add red-black colouring or other additional fields used to maintain =
balance as you wish)

If it=E2=80=99s supposed to represent a set, and a high-level set API is =
the only exposed interface to the record type for nodes, these should be =
considered the same in the =E2=80=98intuitive=E2=80=99 sense of =
=E2=80=98equal?=E2=80=99, because as a set they have the same contents; =
but simply comparing the fields in the nodes will give a wrong answer of =
#f for this sense.

Making equal? be eqv? on records makes the domain of equal?=E2=80=99s =
graph traversal behaviour very well defined (namely, it applies to datum =
types only).
If you want to make equal? do something more useful on some record =
types, let record types define their own behaviour for it. See Chez =
Scheme=E2=80=99s =E2=80=98Record Equality and Hashing=E2=80=99 manual =
section for a well-designed example of such an extension to standard =
record types. =
<https://cisco.github.io/ChezScheme/csug10.0/objects.html#./objects:h16>
(Note that this design handles cyclical structures correctly.)

There is no semantics of equal? which is correct for all possible record =
types, but =E2=80=98eqv?=E2=80=99 is not *wrong* for any record type.

Daphne

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Daphne Preston-Kendal <dpk@HIDDEN>
Subject: bug#75439: Acknowledgement (Behaviour of equal? on R6RS records
 is wrong by the spec, also the Wrong Thing in general)
Message-ID: <handler.75439.B.173635697125172.ack <at> debbugs.gnu.org>
References: <F88A5CD6-524A-4663-9425-0BAF84997159@HIDDEN>
X-Gnu-PR-Message: ack 75439
X-Gnu-PR-Package: guile
Reply-To: 75439 <at> debbugs.gnu.org
Date: Wed, 08 Jan 2025 17:23:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-guile@HIDDEN

If you wish to submit further information on this problem, please
send it to 75439 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
75439: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D75439
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Last modified: Sun, 12 Jan 2025 05:45:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.