unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Christopher Lemmer Webber <cwebber@dustycloud.org>
To: Zelphir Kaltstahl <zelphirkaltstahl@posteo.de>
Cc: guile-user@gnu.org
Subject: Re: Surprising behavior of eq?
Date: Sun, 20 Sep 2020 08:58:11 -0400	[thread overview]
Message-ID: <87v9g861wc.fsf@dustycloud.org> (raw)
In-Reply-To: <8e1d9874-4659-cca5-03da-c2c0df102c56@posteo.de>

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 = "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 = #f
>>
>> (let ([x '(10 9)]
>>       [y '(10 9)])
>>      (eq? x y))
>> $3 = #t
>> ~~~~
>>
>> Is this intentional or a bug?
>>
>> I first noticed something strange when writing the following code:
>>
>> ~~~~DEFINITION~~~~
>> (define make-multiple-list-remover
>>   (λ (equal-proc)
>>     (λ (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 = (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 = (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 = (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




  reply	other threads:[~2020-09-20 12:58 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-20 12:16 Surprising behavior of eq? Zelphir Kaltstahl
2020-09-20 12:19 ` Zelphir Kaltstahl
2020-09-20 12:58   ` Christopher Lemmer Webber [this message]
2020-09-20 13:09   ` Zelphir Kaltstahl
2020-09-20 13:52     ` John Cowan
2020-09-20 15:37       ` Zelphir Kaltstahl
2020-09-20 16:18         ` tomas
2020-09-20 17:05         ` John Cowan
2020-09-20 20:51           ` Linus Björnstam
2020-09-20 21:42             ` John Cowan
2020-09-20 13:57     ` Stefan Schmiedl
2020-09-20 15:42       ` Zelphir Kaltstahl
2020-09-20 17:26 ` Taylan Kammer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87v9g861wc.fsf@dustycloud.org \
    --to=cwebber@dustycloud.org \
    --cc=guile-user@gnu.org \
    --cc=zelphirkaltstahl@posteo.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).