[R6RS] string->number

[William D Clinger]

Mike quoting Kent:
> > I believe that it's more convenient for string->number to return #f
> > (and never signal errors), but that it's also preferable for the reader
> > to signal an error in such cases.  Unfortunately, this would mean that a
> > read implementation could not rely entirely on string->number to decide
> > what constitutes a syntactically valid notation for a number.
> 
> I'm not sure I get this: After all, `read' can't do anything
> reasonable if the literal is syntactically valid but represents a
> number that the implementation can't represent.  Is this just to
> properly distinguish a &defect from an &implementation-restriction?

I believe Kent was pointing out that the read procedure
cannot rely on string->number to *parse* numbers.  The
read procedure must perform its own parsing to separate
lexically correct external representations for numbers
from incorrect, and from correct representations of other
things.

The read procedure can still rely on string->number to
convert correct external representations of numbers into
the numbers themselves.

That raises two questions:

Is string->number allowed to raise an exception?  I would
prefer to require that it never raises an exception.
(Requiring that it never raises an exception doesn't
preclude it from raising an &implementation-restriction
exception if it runs out of memory or encounters some
equally disastrous problem, but that's an implicit out
for every procedure.)

What should happen when read calls the string->number
procedure with a correct external representation of a
number but string->number returns #f?  This can happen
for many legitimate reasons; Kent gave 0/0 and 0/0# as
examples.

0/0, in my opinion, is a lexically correct syntax for
an exact number, but does not denote any exact number.
Therefore it would be best for the read procedure to
raise an exception when reading 0/0.

0/0#, in my opinion, is a lexically correct syntax for
an inexact number, and should evaluate to +nan.0.

Kent argued that 0/0# should be regarded as (/ 0 0#),
but that too should evaluate to +nan.0.  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
because it violates the general rule that division of
an exact by an inexact yields an inexact, and also does
not satisfy the general exception to that general rule
that allows an exact result to be returned "if that
exact result would be the correct result for all
possible substitutions of exact arguments for the
inexact ones."

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 had raised this
issue before, to no good result (pardon the pun), so
I had put it on my list of issues to be raised during
the period of public review and comment.  If we could
correct this example before the first public draft,
I would be delighted.

Will