GNU bug report logs - #11887
string->number edge cases

Previous Next

Full log

Message #29 received at 11887 <at> debbugs.gnu.org (full text, mbox):

From: Mark H Weaver <mhw <at> netris.org>
To: Peter Bex <Peter.Bex <at> xs4all.nl>
Cc: Andy Wingo <wingo <at> pobox.com>, Ian Price <ianprice90 <at> googlemail.com>,
	11887 <at> debbugs.gnu.org
Subject: Re: bug#11887: string->number edge cases
Date: Wed, 06 Mar 2013 13:11:26 -0500

Hi Peter,

Peter Bex <Peter.Bex <at> xs4all.nl> 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 <ianprice90 <at> googlemail.com> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.