From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-io1-xd32.google.com (mail-io1-xd32.google.com [IPv6:2607:f8b0:4864:20::d32]) by sourceware.org (Postfix) with ESMTPS id 92B793858431 for ; Wed, 5 Jan 2022 08:00:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 92B793858431 Received: by mail-io1-xd32.google.com with SMTP id y11so42100905iod.6 for ; Wed, 05 Jan 2022 00:00:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=cjEZfz50+Y1P7x0aGA45Vki+HTjqNqCA2JEVcUix3Cs=; b=L6uyhqDbxHmTCnleXQv0D0qtISAPpVVuSGFY8MD1PEVyY82OyUlwUQusAyRfEhvE2x eaxYjno3RdrD4MQoDqdJEcZWwbrVGFhB2TPEYAbrMjCo+cEpkg9vSH9nLh2rhQr284js yDlbup+lSbD45rmWSJeWWmg5ncxugk1PJL54+m5SfFvAlBlNjWqPujQshemB9zmPEOlV pqRGXIU4HXbusgbo9IJJUj94Z6iP/LUgNkBlMjsZ5wkv74srWC/EAOuBFlMVNW0XxQJ5 uXbT5KqEV5RG6pJ/SjizM7IGRsF2HKRUs+wCwZ+kr+H4Ld6u31Vc76AUKc5KRZGdyVBR vq3w== X-Gm-Message-State: AOAM530SKHhJv3tEnPcNWHrVyheWoxNwTXDMfbynZpF2xpVIkGqeYzsS k2dzUpbnRbpfkr+VFRJhpQAh7uTGhjYgS9v1PrHV/0mkUmI3FA== X-Google-Smtp-Source: ABdhPJwv32DfcHWIDvlLsQDq7mzfKalDQwtrNDHc9W8sssrApEaidYJm8QhL+a8g9PjQrfwpdNNnUjmKuVMI/VsLC+E= X-Received: by 2002:a05:6638:2615:: with SMTP id m21mr22765263jat.271.1641369645844; Wed, 05 Jan 2022 00:00:45 -0800 (PST) MIME-Version: 1.0 From: Panicz Maciej Godek Date: Wed, 5 Jan 2022 09:00:35 +0100 Message-ID: Subject: Rationale for providing "equal?"-like "equals" method for gnu.lists.Pair To: kawa@sourceware.org X-Spam-Status: No, score=-0.5 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: kawa@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Kawa mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Jan 2022 08:00:51 -0000 I'd like to know what the rationale for providing the "equals" method with "structural identity" is. I found it problematic in at least one respect: I have decided to use Java's weak hash tables to represent "properties" attached to cons-cells. However, since those hash tables rely on the Object's "equals" method, the table is unable to distinguish between two different cons-cells that point to the same object. I came up with two solutions to this problem. The first one was patching the implementation of Pair, simply by removing the implementations of the equals method is LList and its subclasses. (IIRC there were some failing tests after the change, but I didn't investigate further) The second solution was simply subclassing gnu.lists.Pair and overriding its equals and hashCode methods, as I did here: https://github.com/panicz/grasp-android/blob/master/stages/stage6/src/org/scheme/parse.scm It works, but the "equal?" semantics for cons-cells doesn't seem right to me, so I wonder what was the reason for providing it, and whether there is some code which relies on it