OP, I don't know where you read that, or how you came to that
conclusion as it is not consistent with either my reading of the
R[56]RS or my experience of various scheme implementations.
5.0 and 5 were not considered equal because one was an integer and the other was a float.
This is incorrect, both are integers. The difference is in exactness,
specifically, the former is an inexact integer, and the latter is an
exact integer. Equality is a separate issue, and has been dealt with
be
>>4. I'd also like to point out that Scheme has no notion of
a float
[1] and that while floating point is the usual implementation
method for inexact arithmetic, it is not required to be that way
[2][3].
You weren’t even allowed to do (4 + 6.0.)
If I were to be an asshole, I'd say that's because Scheme does not
support a
4 function, nor any form of infix arithmetic
[4], and
6.0. is not a valid token in Scheme.
I think you'll find that
(+ 4 6.0) is valid in both the R5RS and the
R6RS, and presumably in earlier versions of the report too. According
to the R5RS,
+ has the interface
(+ z1 ...) [5], which means that
it
accepts 1 or more complex numbers[6] and as floating point numbers
are
real?, they are also
complex?, and therefore acceptable to
+.
R6RS saves you the bother of remembering a convention such as
"z = complex number", by explicitly stating that all arithmetic
procedures accept both exact and inexact arguments.
[7]
The only way a standards-compliant Scheme could fail on that example
is if it did not support either exact arithmetic, or inexact
arithmetic at all
[8], and that is very different from the type
mismatch you are implying.
>>2
racket ftw
Correct arithmetic is hardly specific to Racket, indeed it should only
be wrong in implementations like SSCM, SigScheme and Dream, as they do
not support inexact arithmetic
[9].
[sub]--
1.
http://trac.sacrideo.us/wg/wiki/NumericTower
--
1. Some could argue that the R6RS implies it by the (rnrs arithmetic
flonums) library, but it specifically states that a floating point
representation is not required. (see 3)
2. "An implementation may use floating point and other approximate
representation strategies for inexact numbers."
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2.3
3. "Note that this does not imply that an implementation must use
floating-point representations."
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-6.html#node_sec_3.3
4. It can of course be added as a library, although I've never used
any of them. I'd assume they all work by having an infix keyword in
the operator position [so your would be (infix 4 + 6.0)], similary to
the way Marco Maggi's infix library works (https://github.com/marcomaggi/Infix).
5. http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2.5
6. "The following naming conventions also imply type restrictions:
<snipped>
z, z1, ... zj, ... complex number"
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-4.html#%_sec_1.3.3
7. "The procedures described here implement arithmetic that is generic
over the numerical tower described in chapter 3. The generic
procedures described in this section accept both exact and inexact
number objects as arguments, performing coercions and selecting the
appropriate operations as determined by the numeric subtypes of their
arguments."
http://www.r6rs.org/final/html/r6rs/r6rs-Z-H-14.html#node_sec_11.7
8. The R5RS explicitly allows an implementation to support less than
the full numeric tower,
"Implementations of Scheme are not required to implement the whole
tower of subtypes given in section 6.2.1, but they must implement a
coherent subset consistent with both the purposes of the
implementation and the spirit of the Scheme language."
http://www.schemers.org/Documents/Standards/R5RS/HTML/r5rs-Z-H-9.html#%_sec_6.2.3
whereas R6RS requires a full tower. See 9, for more thorough take on
tower support.
9. http://trac.sacrideo.us/wg/wiki/NumericTower
I know he'll never read this, but special thanks to John Cowan for his
excellent list gathering as part of the R7RS WG process.