From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daphne Preston-Kendal Newsgroups: gmane.lisp.guile.bugs Subject: bug#75439: Behaviour of equal? on R6RS records is wrong by the spec, also the Wrong Thing in general Date: Wed, 8 Jan 2025 18:22:24 +0100 Message-ID: Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3776.700.51.11.1\)) 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="35196"; mail-complaints-to="usenet@ciao.gmane.io" To: 75439@debbugs.gnu.org Original-X-From: bug-guile-bounces+guile-bugs=m.gmane-mx.org@gnu.org Wed Jan 08 18:23:30 2025 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 1tVZmD-0008xL-0o for guile-bugs@m.gmane-mx.org; Wed, 08 Jan 2025 18:23:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tVZlo-0001dP-H6; Wed, 08 Jan 2025 12:23:04 -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 1tVZlm-0001cY-LR for bug-guile@gnu.org; Wed, 08 Jan 2025 12:23:02 -0500 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 1tVZlm-0005c6-Bn for bug-guile@gnu.org; Wed, 08 Jan 2025 12:23:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=Date:Mime-Version:From:To:Subject; bh=syH0fnanoOWmLwH4LrF2Mrgl+Xn3sHdmXzAwhXOEg5o=; b=byj8AHmAby72Wl/rGxbLYvsEaqNxzDkrmZeD0pgwxqSszXU1xZ3bFrDBwtRdLrEhpZV5+V9BCbC0/q8g/zt44tGi5XJHBEwG3la0AGJnF8qSLgokvGqfiSyhyNfEHZv2WQRJ4MWgbXj3zf2QpfDpS9EooUD6DQVw96/lK6+Gy4hHWrgkna4Tre4NHsEkQE3JNEq6EqSKuqgfOPFTNjwmREc6Szzr+lWX7jHJmL95s+FPfn/UrjLETDt3znmf12+ua/Xi7P5WVNZouGEDN/Qq2iqPT3AeIotkS6nwrS2SFVM7oTD/lEyXcnyiBPNgVOQMMOCEu8VG1+5oAqWkdz1W9Q==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tVZlm-0006YO-54 for bug-guile@gnu.org; Wed, 08 Jan 2025 12:23:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daphne Preston-Kendal Original-Sender: "Debbugs-submit" Resent-CC: bug-guile@gnu.org Resent-Date: Wed, 08 Jan 2025 17:23:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 75439 X-GNU-PR-Package: guile X-Debbugs-Original-To: bug-guile@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.173635697125172 (code B ref -1); Wed, 08 Jan 2025 17:23:01 +0000 Original-Received: (at submit) by debbugs.gnu.org; 8 Jan 2025 17:22:51 +0000 Original-Received: from localhost ([127.0.0.1]:48731 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tVZla-0006Xu-9N for submit@debbugs.gnu.org; Wed, 08 Jan 2025 12:22:50 -0500 Original-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 ) id 1tVZlX-0006Xc-Jh for submit@debbugs.gnu.org; Wed, 08 Jan 2025 12:22:48 -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 1tVZlS-0000wt-4x for bug-guile@gnu.org; Wed, 08 Jan 2025 12:22:42 -0500 Original-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 ) id 1tVZlP-0005ah-PW for bug-guile@gnu.org; Wed, 08 Jan 2025 12:22:41 -0500 Original-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 ; Wed, 8 Jan 2025 12:22:37 -0500 (EST) Original-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: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgeefuddrudeggedgleelucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdggtfgfnhhsuhgsshgtrhhisggvpdfu rfetoffkrfgpnffqhgenuceurghilhhouhhtmecufedttdenucgoufhushhpvggtthffoh hmrghinhculdegledmnecujfgurhephfgtgfgguffkfffvofesthhqmhdthhdtjeenucfh rhhomhepffgrphhhnhgvucfrrhgvshhtohhnqdfmvghnuggrlhcuoeguphhksehnohhntg gvfihorhgurdhorhhgqeenucggtffrrghtthgvrhhnpeeiheehgffgffeiveekheejgfff ffeigeffueffiedufeekueevffefveegfeejleenucffohhmrghinhepghhithhhuhgsrd hiohenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegu phhksehnohhntggvfihorhgurdhorhhgpdhnsggprhgtphhtthhopedupdhmohguvgepsh hmthhpohhuthdprhgtphhtthhopegsuhhgqdhguhhilhgvsehgnhhurdhorhhg X-ME-Proxy: Feedback-ID: ibc314252:Fastmail Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Wed, 8 Jan 2025 12:22:36 -0500 (EST) X-Mailer: Apple Mail (2.3776.700.51.11.1) Received-SPF: pass client-ip=103.168.172.154; envelope-from=dpk@nonceword.org; 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-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:11157 Archived-At: 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. = (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