[R6RS] string->number

[Michael Sperber]

William D Clinger <will at ccs.neu.edu> writes:

> 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.

I still don't understand.  Why is it not correct for `read' to always
raise an exception if string->number returns #f?

> Is string->number allowed to raise an exception?  

That, I believe, is consistent with Kent's implementation choice,
which I also prefer.

> 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

I agree.

> 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.

Is there explicit evidence or did it just get stuck in the document
and then overlooked?  (It sure got overlooked by me.)

> 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.

Let's.

-- 
Cheers =8-} Mike
Friede, Völkerverständigung und überhaupt blabla