(= 4 4.0)

[Aubrey Jaffer <jaffer@martigny.ai.mit.edu>]

   Date: Fri, 20 May 94 14:06:11 -0400
   From: Chris Hanson <cph@martigny.ai.mit.edu>

      Date: Fri, 20 May 94 12:22:06 -0400
      From: Aubrey Jaffer <jaffer@martigny.ai.mit.edu>

      Can a conforming R4RS implementation have exact integers and inexact
      numbers, but no inexact integers?  Stated another way, can a
      conforming R4RS implementation return #f from (= 4 4.0) ?

      Some other implications are:
       INTEGER? would return #f for all inexacts.
       QUOTIENT, REMAINDER, MODULO, GCD, LCM, ODD?, and EVEN? would take
      only exact arguments.
       ZERO? would return #t only for exact 0 argument.

      The only fly I have found in the ointment is in the description of
      FLOOR, CEILING, TRUNCATE, and ROUND where it says that what is
      returned is an integer and must have the same exactness as the
      argument.

   This is what I interpret you to be saying:

       I am building an implementation with exact integers and inexact
       rationals implemented as floating-point numbers.  Although
       floating-point numbers have representations for integers, I want to
       pretend that these numbers are not integers so I don't have to
       implement the integer operations on them.

Close.  I already have an implementation with exact integers and
inexact complexes.  My QUOTIENT, REMAINDER, MODULO, GCD, LCM, ODD?,
and EVEN? don't accept inexact arguments.  I think if I make (= 4 4.0)
==> #f I will be much closer to conformance in this area.

   While there are some weak arguments that this is inconsistent with the
   letter of the report, the real problem is that it is inconsistent with
   the intent.  It's easy to support inexact integers, and it is useful
   to do so; why not just do it?

It is not easy to support them if arithmetic is not done with generic
type dispatch.  My QUOTIENT, REMAINDER, MODULO, GCD, LCM, ODD?, and
EVEN?  cannot coerce to exact integers if bignums are not available,
so separate code would have to be written to support them.  (No, I
don't think this shows the benefit of generic arithmetic.  Computing
GCD of inexacts makes as much sense to me as asking if an inexact is
PRIME?)