[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13741: guile-2.0: optimize, and eq-ness of literals (test-suite)

From: Andy Wingo
Subject: bug#13741: guile-2.0: optimize, and eq-ness of literals (test-suite)
Date: Mon, 18 Feb 2013 18:19:23 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux)

On Mon 18 Feb 2013 10:16, address@hidden (Ludovic Courtès) writes:

> Daniel Hartwig <address@hidden> skribis:
>>   scheme@(guile-user)> (define x 1/2)
>>   scheme@(guile-user)> (eq? x 2/4)
>>   $7 = #f
>>   scheme@(guile-user)> ,optimize (eq? x 2/4)
>>   $8 = (eq? x 1/2)
>>   scheme@(guile-user)> (define y 2/4)
>>   scheme@(guile-user)> (eq? x y)
>>   $9 = #f
>>   scheme@(guile-user)> ,optimize (define y 2/4)
>>   $10 = (define y 1/2)
> Quoth R5RS:
>      `Eq?''s behavior on numbers and characters is
>      implementation-dependent, but it will always return either true or
>      false, and will return true only when `eqv?' would also return
>      true.  `Eq?' may also behave differently from `eqv?' on empty
>      vectors and empty strings.
> What we may get wrong is that it looks as if it doesn’t always return
> either true or false, because the behavior depends on whether one of the
> operands is a literal.
> However, it’s fundamentally wrong to rely on eq? to compare numbers.  So
> the test case you mention seems buggy, to start with.

Agreed, FWIW.  Fractions are allocated on the heap, and eq? picks out
the difference between heap objects.  Sometimes two values are the same
object, and sometimes not.

Closing the bug, but please follow up with any questions.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]