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

[Daniel Hartwig]

Version: 2.0.7
# stable-2.0, around commit: 3d2b267
# ./configure (no arguments)

hash.test has a failing case:

  FAIL: tests/hash.test: hash-set and hash-ref:
    ;; 1/2 and 2/4 are equal? and eqv? but not eq?
    (pass-if (equal? #f
                     (let ((table (make-hash-table)))
                       (hashq-set! table 1/2 (quote foo))
                       (hashq-ref table 1/2))))

which may be due to the optimizer or other component working on
literals:

  scheme@(guile-user)> (eqv? 1/2 2/4)
  $1 = #t
  scheme@(guile-user)> (eq? 1/2 2/4)
  $2 = #f
  scheme@(guile-user)> ,optimize (eq? 1/2 2/4)
  $3 = #f
  scheme@(guile-user)> (hashq 1/2 31)
  $4 = 6
  scheme@(guile-user)> (hashq 2/4 31)
  $5 = 20
  scheme@(guile-user)> ,optimize (hashq 2/4 31)
  $6 = (hashq 1/2 31)
  scheme@(guile-user)> ;; uh oh

The ramifications reach beyond hash functions:

  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)

I recall some discussion where it was made clear that literals can not
be assumed eq?, and that *at least* eqv? should be used to compare
numeric values unless they are known to be the same value (i.e. ‘(define
y x) (eq? x y)’).

Is that right?  This particular test and some others properly should
fade away then, or at least drop the eq-case.