Bug in documentation for eq? ?

Bug in documentation for eq? ?

[David Kastrup]

I read

     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*

I think that is wrong.  A variable reference can't really be anything
except eq? to itself in my opinion.  As long as a Scheme object is not
being manipulated in any manner, it should stay eq? to itself.

What am I missing?

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[Andy Wingo]

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.  Therefore that expression is
equivalent to

  (eq? (+ 2 3) (+ 2 3))

which is unspecified.

In summary, I think the documentation is correct.

Regards,

Andy
-- 
http://wingolog.org/

Re: Bug in documentation for eq? ?

[David Kastrup]

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

Re: Bug in documentation for eq? ?

[David Kastrup]

David Kastrup <dak@gnu.org> writes:

> 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.

So that we can have (eq? x x) but not (eq? (car x) (car x)).

I really don't care what the standard claims.  That a Scheme object
should be able to become un-eq? to itself just because it is a number is
nonsense.  That different number expressions might or might not end up
as one object because of a lack of identity is fine.  But that a Scheme
object might split into several un-eq? identities is schizophrenic.
That would violate more invariants than anything.

It is fine if the optimizer decides not tracking the identity of
numbers.  But that means that, absent any reliable identity information,
it must declare equal numbers as eq?, not as un-eq?.

This is a one-way street.  Other options don't make sense.

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[Andy Wingo]

Hi,

[bunch of examples]
> Which of the above would you consider unspecified?

As the Scheme standard clearly states, all the ones comparing numbers
with eq?.  You find some of them surprising; that is your problem ;)  The
answer is to not compare numbers with eq?.

Regards,

Andy
-- 
http://wingolog.org/

Re: Bug in documentation for eq? ?

[Noah Lavine]

Hello,

I think you're talking past each other a little bit. Andy is saying
that the Scheme standard doesn't specify eq? on numbers. David is
saying that an object should always be eq? to itself, no matter what
object.

I believe David's claim is that Guile should guarantee that a variable
is eq? to itself, even though the standard doesn't.

I don't know what the right answer is, but I think that's what this
discussion should be about.
Noah

On Wed, Jun 20, 2012 at 9:17 AM, Andy Wingo <wingo@pobox.com> wrote:
> Hi,
>
> [bunch of examples]
>> Which of the above would you consider unspecified?
>
> As the Scheme standard clearly states, all the ones comparing numbers
> with eq?.  You find some of them surprising; that is your problem ;)  The
> answer is to not compare numbers with eq?.
>
> Regards,
>
> Andy
> --
> http://wingolog.org/
>

Re: Bug in documentation for eq? ?

[Andy Wingo]

On Wed 20 Jun 2012 15:41, Noah Lavine <noah.b.lavine@gmail.com> writes:

> I believe David's claim is that Guile should guarantee that a variable
> is eq? to itself, even though the standard doesn't.

We could guarantee this, but it would prevent a number of interesting
and permissible optimizations, for questionable semantic value.  You
should not consider variables as having identity, only values.  Numbers
do not have identity, so Guile can do with them as it pleases.

Andy
-- 
http://wingolog.org/

Re: Bug in documentation for eq? ?

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> Hi,
>
> [bunch of examples]
>> Which of the above would you consider unspecified?
>
> As the Scheme standard clearly states, all the ones comparing numbers
> with eq?.  You find some of them surprising; that is your problem ;)  The
> answer is to not compare numbers with eq?.

You are confused.  I am not comparing numbers when writing (eq? x x).
I am checking the identity of an object.  Whether that object is a
number or not, and if so, what value it has, is irrelevant.

If the Scheme standard states that

(and (pair? x) (not (eq? (car x) (car x))))

can return #t in a conforming implementation, that means that the
standard failed to do its job for weeding out implementations with
unusable behavior.

But that does not mean that a given implementation should consider
unusability to be a worthwhile goal.

Cf. <URL:http://www.gnu.org/prep/standards/standards.html#Non_002dGNU-Standards>

I would consider it an extremely bad idea if Guile (or for that matter,
any other Scheme implementation) would ever produce anything but #t for
(eq? v v) regardless of what v has been bound to.  And I see no point in
threatening the user that it might do so in an alternate universe.

Again: it is fine if an optimizer chooses not to track object identities
for numeric values.  But if it doesn't, it needs to assume they are eq?
when equal rather than some random choice.

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 20 Jun 2012 15:41, Noah Lavine <noah.b.lavine@gmail.com> writes:
>
>> I believe David's claim is that Guile should guarantee that a variable
>> is eq? to itself, even though the standard doesn't.
>
> We could guarantee this, but it would prevent a number of interesting
> and permissible optimizations, for questionable semantic value. 

Name one.

> You should not consider variables as having identity, only values.
> Numbers do not have identity, so Guile can do with them as it pleases.

Let's throw an error whenever using eq? on a number or running memq on a
list containing a number.

That would be interesting and apparently permissible behavior.  I have
my doubts that users will be impressed favorably.

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[Andy Wingo]

On Wed 20 Jun 2012 16:27, David Kastrup <dak@gnu.org> writes:

> I am not comparing numbers when writing (eq? x x).
> I am checking the identity of an object.  Whether that object is a
> number or not, and if so, what value it has, is irrelevant.

"x" is not an object: it is a variable.  Variables do not have identity.

Andy
-- 
http://wingolog.org/

Re: Bug in documentation for eq? ?

[Andy Wingo]

On Wed 20 Jun 2012 16:31, David Kastrup <dak@gnu.org> writes:

> Andy Wingo <wingo@pobox.com> writes:
>
>> interesting and permissible optimizations
>
> Name one.

FWIW, eta-conversion (for primitives).  Copy propagation for the
purposes of inlining (a la Waddell).  Storing numbers in unboxed form,
and only reifying a Scheme value when they need to leave a procedure.

Andy
-- 
http://wingolog.org/

Re: Bug in documentation for eq? ?

[Pierpaolo Bernardi]

On Wed, Jun 20, 2012 at 4:27 PM, David Kastrup <dak@gnu.org> wrote:
> Andy Wingo <wingo@pobox.com> writes:
>
> If the Scheme standard states that
>
> (and (pair? x) (not (eq? (car x) (car x))))
>
> can return #t in a conforming implementation, that means that the
> standard failed to do its job for weeding out implementations with
> unusable behavior.

The standard did its job by defining eqv?

Do a (define eq? eqv?) at the start of your programs and you have what
you are asking for.

Re: Bug in documentation for eq? ?

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 20 Jun 2012 16:27, David Kastrup <dak@gnu.org> writes:
>
>> I am not comparing numbers when writing (eq? x x).
>> I am checking the identity of an object.  Whether that object is a
>> number or not, and if so, what value it has, is irrelevant.
>
> "x" is not an object: it is a variable.  Variables do not have identity.

Variables have values.  Values are scheme objects.  Scheme objects have
identity.  Numbers of identical numeric value may or may not be mapped
to identical scheme objects.  But identical scheme objects may not
choose to become unidentical.  Something like

(while (and (list? x) (pair? x))
  (set! x (delq (car x) x)))

should be guaranteed to terminate in any sane implementation, even if
the list contains numbers.

Whatever.  It is quite clear that you can't be bothered with caring
about sane semantics when the standard gives you a free pass.

Forget I asked.  I don't see the point in further serving as a target
for pseudointellectual mockery.

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[David Kastrup]

Andy Wingo <wingo@pobox.com> writes:

> On Wed 20 Jun 2012 16:31, David Kastrup <dak@gnu.org> writes:
>
>> Andy Wingo <wingo@pobox.com> writes:
>>
>>> interesting and permissible optimizations
>>
>> Name one.
>
> FWIW, eta-conversion (for primitives).  Copy propagation for the
> purposes of inlining (a la Waddell).  Storing numbers in unboxed form,
> and only reifying a Scheme value when they need to leave a procedure.

How do you create un-eq? values from the same variable here?

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[David Kastrup]

Pierpaolo Bernardi <olopierpa@gmail.com> writes:

> On Wed, Jun 20, 2012 at 4:27 PM, David Kastrup <dak@gnu.org> wrote:
>> Andy Wingo <wingo@pobox.com> writes:
>>
>> If the Scheme standard states that
>>
>> (and (pair? x) (not (eq? (car x) (car x))))
>>
>> can return #t in a conforming implementation, that means that the
>> standard failed to do its job for weeding out implementations with
>> unusable behavior.
>
> The standard did its job by defining eqv?
>
> Do a (define eq? eqv?) at the start of your programs and you have what
> you are asking for.

Except efficiency.  It appears you are confused about what I am asking
for.

I am perfectly fine with the possibility (eq? 0 0) => #f
I am not fine with the possibility (eq? (car x) (car x)) => #f

But it is clear that there is no interest in providing sane invariants
for Guile programmers, so we can just quit this absurdity.

-- 
David Kastrup

Re: Bug in documentation for eq? ?

[Andy Wingo]

On Wed 20 Jun 2012 17:16, David Kastrup <dak@gnu.org> writes:

> Whatever.  It is quite clear that you can't be bothered with caring
> about sane semantics when the standard gives you a free pass.
>
> Forget I asked.  I don't see the point in further serving as a target
> for pseudointellectual mockery.

I am sorry to have to say this, but please do not post to this list any
more.  Thank you in advance.

Andy
-- 
http://wingolog.org/