[R6RS] string->number
dyb at cs.indiana.edu
dyb at cs.indiana.edu
Wed Aug 30 12:02:51 EDT 2006
> I still don't understand. Why is it not correct for `read' to always
> raise an exception if string->number returns #f?
It probably can, but the message might be different. I'm not sure that
the observation is important for R6RS.
> > Is string->number allowed to raise an exception?
>
> That, I believe, is consistent with Kent's implementation choice,
> which I also prefer.
If you mean that it should not raise an exception, then I also agree, and
I suggest we just make the change unless either Matthew or Anton wants to
argue against it.
> > In the current draft of the R6RS, however, (/ 0 0#) is given as an
> > example whose result could be an exact 0 or +nan.0.
> >
> > In my opinion, the exact 0 result is just plain wrong
In my interpretation, IEEE +0.0 is some tiny positive number, not zero,
and IEEE -0.0 is some tiny negative number, not zero. If this were not
the case, i.e., if +0.0 or -0.0 could be exactly zero, division by either
of these quantities would have to produce NaN. With this interpretation,
(/ 0 +0.0) and (/ 0 -0.0) should return 0, since 0 divided by some tiny
non-zero quantity is 0. By the same rationale, (* 0 +nan.0) should also
return 0.
> > That, of course, is just my opinion, based on my
> > personal opinion that an exact 0 is not the correct
> > result of (/ 0 0). On the other hand, some of the
> > other editors evidently regard 0 as the correct result
> > of (/ 0 0), which is why the example is as it is in
> > the current draft of the R6RS.
I've explained my rationale before this, and as you can see again it is
not based on the assumption that 0 is the correct result of (/ 0 0).
Kent
More information about the R6RS
mailing list