bug#11887: string->number edge cases

[Mark H Weaver]

Hi Peter,

Peter Bex <address@hidden> writes:

> On Tue, Mar 05, 2013 at 02:04:55PM -0500, Mark H Weaver wrote:
>> FYI, I produced a simple patch a while back to fix this (see below), but
>> it had an interesting side effect: it caused the reader to read things
>> like "3/0" and "4+3/0i" as symbols.  More generally, anything for which
>> 'scm_string_to_number' returns false is treated as a symbol by 'read'.
>
> I think this is simple and at least internally consistent.  Several
> Schemes assume something like 1/0 is a symbol; Chicken does this as
> well, with the numbers egg loaded, so does Gambit.
[...]
> This is also related to how string->number deals with it; if it
> returns #f it is essentially saying "this is not valid numerical syntax"
> and should fail to parse as a number.  Not raising an exception on
> (string->number "1/0) but raising an exception on
> (with-input-from-string "1/0" read) is a bit odd, I'd say.

Thanks, this makes me feel somewhat better about it.  I guess it's okay.

> On Tue, Mar 05, 2013 at 03:49:13PM +0100, Andy Wingo wrote:
> > Hi Ian,
> > 
> > On Mon 09 Jul 2012 14:29, Ian Price <address@hidden> writes:
> > 
> > > PARSE ERROR         ("+InF.0" +inf.0 "+inf.0" "+Inf.0") => #f
> > > PARSE ERROR         ("-iNF.0" -inf.0 "-inf.0" "-Inf.0") => #f
> > > PARSE ERROR         ("+NAN.0" +nan.0 "+nan.0" "+NaN.0") => #f
> > 
> > These are not errors.  +NAN.0 is not even not a number :)
> 
> I double-checked, but in the upcoming R7RS it is (see 7.1, paragraph 2 of
> draft 7).  It looks like R6RS was case-sensitive in its numerical syntax
> and +NAN.0 is disallowed by it.

Thanks for looking this up.  Given that it's allowed by the latest R7RS
draft, I think we should allow these too.

I've written a patch to fix these issues, and will send it in my next
email.

    Regards,
      Mark