Hi Peter,
Peter Bex <peter....@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 <ianpric...@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
