GNU bug report logs - #75439
Behaviour of equal? on R6RS records is wrong by the spec, also the Wrong Thing in general

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: guile; Reported by: Daphne Preston-Kendal <dpk@HIDDEN>; dated Wed, 8 Jan 2025 17:23:01 UTC; Maintainer for guile is bug-guile@HIDDEN.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 8 Jan 2025 17:22:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Jan 08 12:22:50 2025
Received: from localhost ([127.0.0.1]:48731 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1tVZla-0006Xu-9N
	for submit <at> debbugs.gnu.org; Wed, 08 Jan 2025 12:22:50 -0500
Received: from lists.gnu.org ([2001:470:142::17]:35348)
 by debbugs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.84_2) (envelope-from <dpk@HIDDEN>) id 1tVZlX-0006Xc-Jh
 for submit <at> debbugs.gnu.org; Wed, 08 Jan 2025 12:22:48 -0500
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 <dpk@HIDDEN>) id 1tVZlS-0000wt-4x
 for bug-guile@HIDDEN; Wed, 08 Jan 2025 12:22:42 -0500
Received: from fhigh-a3-smtp.messagingengine.com ([103.168.172.154])
 by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
 (Exim 4.90_1) (envelope-from <dpk@HIDDEN>) id 1tVZlP-0005ah-PW
 for bug-guile@HIDDEN; Wed, 08 Jan 2025 12:22:41 -0500
Received: from phl-compute-08.internal (phl-compute-08.phl.internal
 [10.202.2.48])
 by mailfhigh.phl.internal (Postfix) with ESMTP id 5215A114022C
 for <bug-guile@HIDDEN>; Wed,  8 Jan 2025 12:22:37 -0500 (EST)
Received: from phl-mailfrontend-01 ([10.202.2.162])
 by phl-compute-08.internal (MEProxy); Wed, 08 Jan 2025 12:22:37 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nonceword.org;
 h=cc:content-transfer-encoding:content-type:content-type:date
 :date:from:from:in-reply-to:message-id:mime-version:reply-to
 :subject:subject:to:to; s=fm2; t=1736356957; x=1736443357; bh=sy
 H0fnanoOWmLwH4LrF2Mrgl+Xn3sHdmXzAwhXOEg5o=; b=lYJzco7dvTL5INvDMi
 DTZfQol5sdmm71AM2Do+J3WUsxVRC6H2GbM5YltM1cVw/I0Z7vbWXKdjTQR7wcLl
 rSXySLZgiyzMS8KT8/++Aj5w6PfReS7vrmcd1PNAdKyZIqm/VTwfgJTaTeBWYjud
 fRBCqGcPhRmkOszH09ZVwJP6xnfd08MN9jzeYKYGVC2LHYLzFuSaEfSxcUTvKZ47
 rABzZ6ePsR7sxgprqHzD1Lvk0YZP08KVDINiW5Jxqz09LdPUT7EpaoKyo+QJ3Bll
 IJGADA8jpDKBXrhrj2Kzmf+rVEBoogaNl+i6CgqS1Bf2ATVEDqfoS3i2x9/+2dNS
 p41g==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :content-type:date:date:feedback-id:feedback-id:from:from
 :in-reply-to:message-id:mime-version:reply-to:subject:subject:to
 :to:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=
 1736356957; x=1736443357; bh=syH0fnanoOWmLwH4LrF2Mrgl+Xn3sHdmXzA
 whXOEg5o=; b=oqRgLIgYyXwTyuluvtoM2W963bEcW2pXj04SpWQNmh2Q8rJD4Nn
 ofQAFnktONoEeavXX1IOPLT1AdxEDn3vdqAHg42yVLMGEzvjLg0xmqnPoFyqS9cr
 Z5lHIeDoEsESdkBurPn1oJ+G8xXDKwDP7naUIoAUQcvEeXf4cONLuIn5tSe2nz7a
 13+6JQ0RZtuqwASBIwPhEJa9o8TS+z4WhBmYZzYEcW+oSk61x4ROgXuUxJrCzBBI
 TfeEjQm+kvHqumLxiGkY9CujEbHYZdb9KnRssNdzcD/IZ9CH03Kf7QEPrJc6PrLR
 4OTnaRaQHXUC/8xf6iUJc6gLT2qMlIMnWeg==
X-ME-Sender: <xms:XbR-Z5fz-3mMSJJ1jceb8ppzhyhQsjPsK6p0AU65LlEZYH4Sq-nJ8g>
 <xme:XbR-Z3N9ShbbEIekieloEse69YsDYwBzmZztRK9vJAfDYMDuKi732GRWYfxJEq4EK
 -IuSCiXrFHxx7QKow>
X-ME-Received: <xmr:XbR-ZygU0cF_2eoE2cHMdsv-_NT9ti1ndgMKNJtTUzMdbcKwFh8Ry6JqXsTLTc_z-dBW6tFMayoQ1j0aHP5HzYJ2iA3_c5N2NaUzh0eQdYLCQc4y6aIf5XdI8A>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeggedgleelucetufdoteggodetrfdotf
 fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu
 rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffoh
 hmrghinhculdegledmnecujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtjeenucfh
 rhhomhepffgrphhhnhgvucfrrhgvshhtohhnqdfmvghnuggrlhcuoeguphhksehnohhntg
 gvfihorhgurdhorhhgqeenucggtffrrghtthgvrhhnpeeiheehgffgffeiveekheejgfff
 ffeigeffueffiedufeekueevffefveegfeejleenucffohhmrghinhepghhithhhuhgsrd
 hiohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu
 phhksehnohhntggvfihorhgurdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepsh
 hmthhpohhuthdprhgtphhtthhopegsuhhgqdhguhhilhgvsehgnhhurdhorhhg
X-ME-Proxy: <xmx:XbR-Zy_x5Od01tsZqvkj06lDCb-0akWYmf-AuFdAZxTC3v1DQRvOOg>
 <xmx:XbR-Z1uvwsK2OjiA5Y9gqeH7RB7rwt5N4b7cAFSCa71I_PH91BIzUg>
 <xmx:XbR-ZxEIO-niTVwMfiLdU8wc_OC07DBK53tn5HH_AfJJe7PRM6OJfw>
 <xmx:XbR-Z8NGq_eeFP3gr49UrmuOfu707Q0-ai7HUHPbOD4gZg1WEdEqhQ>
 <xmx:XbR-Z2VTcT5Ei2q1BWnKd7bp2ECvOul3L61mjJqhHqVyX9iY8pncvgA5>
Feedback-ID: ibc314252:Fastmail
Received: by mail.messagingengine.com (Postfix) with ESMTPA for
 <bug-guile@HIDDEN>; Wed, 8 Jan 2025 12:22:36 -0500 (EST)
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\))
Subject: Behaviour of equal? on R6RS records is wrong by the spec, also the
 Wrong Thing in general
Message-Id: <F88A5CD6-524A-4663-9425-0BAF84997159@HIDDEN>
Date: Wed, 8 Jan 2025 18:22:24 +0100
To: bug-guile@HIDDEN
X-Mailer: Apple Mail (2.3776.700.51.11.1)
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-Debbugs-Envelope-To: submit
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





Acknowledgement sent to Daphne Preston-Kendal <dpk@HIDDEN>:
New bug report received and forwarded. Copy sent to bug-guile@HIDDEN. Full text available.
Report forwarded to bug-guile@HIDDEN:
bug#75439; Package guile. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
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.