[R6RS] string->number

[dyb at cs.indiana.edu]

> 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