From: David Kastrup <dak@gnu.org>
To: Andy Wingo <wingo@pobox.com>
Cc: guile-devel@gnu.org
Subject: Re: Bug in documentation for eq? ?
Date: Wed, 20 Jun 2012 13:32:49 +0200 [thread overview]
Message-ID: <87r4tab4m6.fsf@fencepost.gnu.org> (raw)
In-Reply-To: <87oboe2qti.fsf@pobox.com> (Andy Wingo's message of "Wed, 20 Jun 2012 12:58:01 +0200")
Andy Wingo <wingo@pobox.com> writes:
> On Wed 20 Jun 2012 12:40, David Kastrup <dak@gnu.org> writes:
>
>> Numbers and characters are not equal to any other object, but the
>> problem is they're not necessarily `eq?' to themselves either.
>> This is even so when the number comes directly from a variable,
>>
>> (let ((n (+ 2 3)))
>> (eq? n n)) => *unspecified*
>
> Note that this example is taken from R5RS section 6.1.
>
>> A variable reference can't really be anything except eq? to itself in
>> my opinion.
>
> Depends on inlining. Numbers are not considered to have identity, so
> they may be copied in some situations.
I can't see this being such a situation. The number 5 as such does not
have identity. But each individual instance of the number 5 is a Scheme
object, and Scheme objects have identity. That different instances of 5
may or may not compare eq?: no question about that. But the same?
That's just silly.
> In summary, I think the documentation is correct.
I think it is completely absurd. It would mean, for example, that
(memq x (list x))
is generally unspecified. It would mean that things like
(eq? (car x) (car x))
are generally unspecified even when x is a pair.
We have
scheme@(guile-user)> (eq? +nan.0 +nan.0)
$8 = #f
scheme@(guile-user)> (eqv? +nan.0 +nan.0)
$9 = #t
scheme@(guile-user)> (= +nan.0 +nan.0)
$10 = #f
scheme@(guile-user)> (let ((x +nan.0)) (eq? x x))
$11 = #t
scheme@(guile-user)> (let ((x +nan.0)) (eqv? x x))
$12 = #t
scheme@(guile-user)> (let ((x +nan.0)) (= x x))
$13 = #f
And that makes sense since eqv? is supposed to apply to a superset of
eq? while = is working on numerical values.
Which of the above would you consider unspecified?
--
David Kastrup
next prev parent reply other threads:[~2012-06-20 11:32 UTC|newest]
Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-06-20 10:40 Bug in documentation for eq? ? David Kastrup
2012-06-20 10:58 ` Andy Wingo
2012-06-20 11:32 ` David Kastrup [this message]
2012-06-20 11:47 ` David Kastrup
2012-06-20 13:17 ` Andy Wingo
2012-06-20 13:41 ` Noah Lavine
2012-06-20 14:22 ` Andy Wingo
2012-06-20 14:31 ` David Kastrup
2012-06-20 14:47 ` Andy Wingo
2012-06-20 15:19 ` David Kastrup
2012-06-20 14:27 ` David Kastrup
2012-06-20 14:43 ` Andy Wingo
2012-06-20 15:16 ` David Kastrup
2012-06-20 15:29 ` Andy Wingo
2012-06-20 14:56 ` Pierpaolo Bernardi
2012-06-20 15:25 ` David Kastrup
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=87r4tab4m6.fsf@fencepost.gnu.org \
--to=dak@gnu.org \
--cc=guile-devel@gnu.org \
--cc=wingo@pobox.com \
/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).