From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: John Cowan Newsgroups: gmane.lisp.guile.user Subject: Re: Surprising behavior of eq? Date: Sun, 20 Sep 2020 09:52:06 -0400 Message-ID: References: <8e1d9874-4659-cca5-03da-c2c0df102c56@posteo.de> Mime-Version: 1.0 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="32219"; mail-complaints-to="usenet@ciao.gmane.io" Cc: guile-user To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Sep 20 15:52:33 2020 Return-path: Envelope-to: guile-user@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 1kJzlZ-0008JD-3H for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 15:52:33 +0200 Original-Received: from localhost ([::1]:54880 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJzlY-000658-1N for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 09:52:32 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:38358) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJzlN-00064y-AT for guile-user@gnu.org; Sun, 20 Sep 2020 09:52:21 -0400 Original-Received: from mail-qv1-xf2a.google.com ([2607:f8b0:4864:20::f2a]:44689) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kJzlK-0005zi-No for guile-user@gnu.org; Sun, 20 Sep 2020 09:52:21 -0400 Original-Received: by mail-qv1-xf2a.google.com with SMTP id j10so5915054qvk.11 for ; Sun, 20 Sep 2020 06:52:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=InJWZFLttqHRMz3i2dTFVRXDBE4yuy3K1jgyRDYisOc=; b=wQWFdFbQSxZiDUjTG0Fq6AUR54FF/y7RtUgDL8DpxwnP+vzp6HCwrosoBgoDyFEKUj gGMheYVQttNkSqRkCcYIuwfRLtqsOgOIUGHqTU5dxWJ63z62GdpCju5WCyOZJvxtd0nn jkRUk1ogxKCYnwOvqCrMU6cdplnOBY2wcB9toVKo6GDIiYvbbVU86UXsnAUYKuMHgzty M1pCvUE+3PaKFr2gAV+CzO1CHf/cLWqAUeeQ2wDL7WQya/cEm/b5pvI8DhxvzQUkotk+ JhFjhyDaQ7uvmX41ZJqICAVAKVWfPNeWWWeFGaq79vaTY0tZo6cvi9gW6jINcL7SUg3M BPjg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=InJWZFLttqHRMz3i2dTFVRXDBE4yuy3K1jgyRDYisOc=; b=ZsNFx7IT/PwWWUYvG9DmLVJ0Qv5DK75mnVRBLkV7je6Q1/ZMollRY4rO33ML/BdDAz SP23wPlaoTRtdrx7keTGpNNIZJww5VRniVWMjWXFpgoqfLYrdXNAbUpFanVbX4s2q07J mCVU0e+Alvf/3nebm+1MlXqcU/O2pbl8xypEmr2WP4fhWhLrJUsK0kXVPkUnurjUObcu lFIzliCijMdFkV5LA/9eeP4A2L+odpyxVVkzF4w3i//FyowLU0iguYBSjKYeROpM9Imt moAKelUc1eaYvVj6sWWaQFg9v5Al/M/AnxstPqL+eNpMtZ5OQPyrxIvQ9CYD31JGs3Ca yQ2g== X-Gm-Message-State: AOAM531wVsXpCTjL2gYo7iQaYVGwabY8ebUKFPeStmWhqXAFkJznkhEX pyCHlIRNKw24hYiPS2WpisiYW+sGSogS4aZumpU91A== X-Google-Smtp-Source: ABdhPJzXnW/nA2D2jMCNW5srN5koq0mqD5IrDRJqUYP4c+Trw3cB4t3bC10VAoPt2PVYy9MsHEaexA10il+sv/Zg+Ns= X-Received: by 2002:ad4:544a:: with SMTP id h10mr26470491qvt.35.1600609936956; Sun, 20 Sep 2020 06:52:16 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::f2a; envelope-from=cowan@ccil.org; helo=mail-qv1-xf2a.google.com X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Original-Sender: "guile-user" Xref: news.gmane.io gmane.lisp.guile.user:16934 Archived-At: What's happening is that you are trying to compare strings with an inappropriate predicate. Eqv? tests for *identity* (being the same object), whereas equal? tests for *equality* (havng the same structure). Therefore, (equal? "foo" "foo") will always return #t, and almost all the time that's the predicate you should use. The question then is: when are two strings identical and not merely equal? In the general case, they are identical if they are the result of a single constructor. Thus given: (define a (string #\a #\b #\c)) (define b a) then (eqv? a b) =3D> #t But given (define c (string #\a #\b #c)) (define d (string #\a #\b #c)) then (eqv? c d) =3D> #f Finally, we have to deal with string literals. If there is more than one appearance of "xyz" in code, they are all equal, but are they identical? The answer is that it is implementation-dependent. A Scheme is free to consolidate all equal literals into the same object. It looks like Guile does so when they both appear in the same top-level expression, but *not* in different top-level expressions. So given (define e "xyz") (define f "xyz") then (eqv? e f) =3D> #f But (let ((g "xyz") (h "xyz")) (eqv? g h)) =3D> #t, because Guile consolidates the two equal literals into a single object. If you try this on Chibi Scheme, you'll get #f, because Chibi does *not* consolidate string literals. I hope that is helpful. On Sun, Sep 20, 2020 at 9:11 AM Zelphir Kaltstahl < zelphirkaltstahl@posteo.de> wrote: > And I've noticed something more about equality stuff in the context of > tests: > > ~~~~ > (eqv? "a" "a") > $3 =3D #t > > ;; but > > (define char->string > (=CE=BB (c) > (list->string > (list c)))) > > (import > ;; unit tests > (srfi srfi-64)) > > (test-begin "string-utils-test") > > (test-group > "char-to-string-test" > > (test-eqv "char->string converts a character to a string" > "a" > (char->string #\a))) > > (test-end "string-utils-test") > > %%%% Starting test string-utils-test (Writing full log to > "string-utils-test.log") > $2 =3D ("string-utils-test") > :19: FAIL char->string converts a character to a string > # of unexpected failures 1 > ~~~~ > > So while (eqv? ...) gives the correct (?) result, the test procedure > (test-eqv ...) which seems to indicate using (eqv? ...) via its name > does not think of the two strings as equivalent. > > > On 20.09.20 14:19, Zelphir Kaltstahl wrote: > > Sorry, I misclicked "send" when I wanted to further edit my e-mail ... > > > > My Guile version is: > > > > ~~~~ > > (version) > > $6 =3D "3.0.4" > > ~~~~ > > > > On 20.09.20 14:16, Zelphir Kaltstahl wrote: > >> Hello Guile users, > >> > >> I just noticed something weird about eq?. > >> > >> My Guile version is: > >> > >> > >> I get the different results, depending on whether I define some > >> bindings in a let or using define: > >> > >> (In Emacs Geiser:) > >> > >> ~~~~ > >> (define x '(10 9)) > >> (define y '(10 9)) > >> (eq? x y) > >> $2 =3D #f > >> > >> (let ([x '(10 9)] > >> [y '(10 9)]) > >> (eq? x y)) > >> $3 =3D #t > >> ~~~~ > >> > >> Is this intentional or a bug? > >> > >> I first noticed something strange when writing the following code: > >> > >> ~~~~DEFINITION~~~~ > >> (define make-multiple-list-remover > >> (=CE=BB (equal-proc) > >> (=CE=BB (lst unwanted) > >> (let loop ([remaining-list lst]) > >> (cond > >> [(null? remaining-list) > >> '()] > >> [(equal-proc (car remaining-list) unwanted) > >> (loop (cdr remaining-list))] > >> [else > >> (cons (car remaining-list) > >> (loop (cdr remaining-list)))]))))) > >> ~~~~ > >> > >> ~~~~TEST~~~~ > >> (let ([a '(9 10)] > >> [b '(9 10)]) > >> (test-equal "make-multiple-list-remover-03" > >> `(1 2 (3) (4) ,a) > >> ((make-multiple-list-remover eq?) > >> `(a b (c) (d) ,a) b))) > >> ~~~~ > >> > >> I was wondering, why the test fails. I think (eq? ...) should not be > >> able to see the equivalence of both lists a and b, just like when > >> defined using (define ...). > >> > >> I can also run it in the REPL and see the difference: > >> > >> ~~~~ > >> (define a '(9 10)) > >> (define b '(9 10)) > >> ((make-multiple-list-remover eq?) > >> `(a b (c) (d) ,a) b) > >> $4 =3D (a b (c) (d) (9 10)) > >> > >> (let ([a '(9 10)] > >> [b '(9 10)]) > >> ((make-multiple-list-remover eq?) > >> `(a b (c) (d) ,a) b)) > >> $5 =3D (a b (c) (d)) > >> ~~~~ > >> > >> Somehow the bindings of let seem to be different from the bindings > >> created using define. What about using define inside let? > >> > >> ~~~~ > >> > >> ~~~~ > >> -- > >> repositories: https://notabug.org/ZelphirKaltstahl > > Somehow the bindings of let seem to be different from the bindings > > created using define. What about using define inside let? > > > > ~~~~ > > (let ([unrelated 'bla]) > > (define a '(9 10)) > > (define b '(9 10)) > > ((make-multiple-list-remover eq?) > > `(a b (c) (d) ,a) b)) > > $7 =3D (a b (c) (d)) > > ~~~~ > > > > So there the define usage also differs from when I use define on the to= p > > level. Perhaps that is the difference? On which level the bindings are > > defined? > > > > Regards, > > Zelphir > > > -- > repositories: https://notabug.org/ZelphirKaltstahl > >