From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Christopher Lemmer Webber Newsgroups: gmane.lisp.guile.user Subject: Re: Surprising behavior of eq? Date: Sun, 20 Sep 2020 08:58:11 -0400 Message-ID: <87v9g861wc.fsf@dustycloud.org> 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="7848"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: mu4e 1.4.12; emacs 26.3 Cc: guile-user@gnu.org To: Zelphir Kaltstahl Original-X-From: guile-user-bounces+guile-user=m.gmane-mx.org@gnu.org Sun Sep 20 14:58:38 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 1kJyvM-0001tj-MS for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 14:58:36 +0200 Original-Received: from localhost ([::1]:52044 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kJyvL-0003IJ-KX for guile-user@m.gmane-mx.org; Sun, 20 Sep 2020 08:58:35 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58582) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJyvB-0003Hx-FM for guile-user@gnu.org; Sun, 20 Sep 2020 08:58:25 -0400 Original-Received: from dustycloud.org ([50.116.34.160]:42734) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kJyv9-000098-Ko for guile-user@gnu.org; Sun, 20 Sep 2020 08:58:25 -0400 Original-Received: from twig (localhost [127.0.0.1]) by dustycloud.org (Postfix) with ESMTPS id ECC12265C3; Sun, 20 Sep 2020 08:58:21 -0400 (EDT) In-reply-to: <8e1d9874-4659-cca5-03da-c2c0df102c56@posteo.de> Received-SPF: pass client-ip=50.116.34.160; envelope-from=cwebber@dustycloud.org; helo=dustycloud.org X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/20 08:58:22 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action 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:16932 Archived-At: My guess, without really knowing, is this is some sort of optimization. But it could affect things I suppose if someone is intending to construct lists for the main purpose of creating different eq-differentiated identifiers (eg as keys for a hasheq)... Zelphir Kaltstahl writes: > 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? >> >> ~~~~ >> >> ~~~~ >> --=20 >> 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 top > level. Perhaps that is the difference? On which level the bindings are > defined? > > Regards, > Zelphir