[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: Daniel Hartwig
Subject: bug#13741: guile-2.0: optimize, and eq-ness of literals (test-suite)
Date: Mon, 18 Feb 2013 18:02:15 +0800

On 18 February 2013 17:16, Ludovic Courtès <address@hidden> wrote:
> 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.

I took that to mean only that eq? always returns a boolean, rather
than requiring it to return the same boolean given the same numeric
arguments.  It would be fine to simplify some rationals and not
others, as this action does not affect the outcome of eqv?.

> However, it’s fundamentally wrong to rely on eq? to compare numbers.  So
> the test case you mention seems buggy, to start with.
> Ludo’.

Right, the test cases involving eq-ness of numbers are broken, should
be removed.  Patch to follow.

reply via email to

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