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
Daphne Preston-Kendal <dpk@HIDDEN>
:bug-guile@HIDDEN
.
Full text available.bug-guile@HIDDEN
:bug#75439
; Package guile
.
Full text available.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.