[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Chicken-hackers] [PATCH] string->number shouldn't raise errors but retu
From: |
Peter Bex |
Subject: |
[Chicken-hackers] [PATCH] string->number shouldn't raise errors but return #f on failure |
Date: |
Fri, 23 Mar 2012 23:21:51 +0100 |
User-agent: |
Mutt/1.4.2.3i |
Hi all,
After adding some problematic cases found by John Cowan in the
numbers egg, I decided to port some of those tests to the Chicken
tests as well. Doing so I found two problems:
The first is that (string->number "#e+inf.0") raises an error:
"Error: (inexact->exact) inexact number cannot be represented as an exact
number: +inf.0"
I think it should return #f instead, since that's what it normally
does when you pass nonsense to it. After discussion on the R7RS WG1
list, it seems that this is also the intended behavior of string->number
in R7. R6RS has a line that explicitly says string->number never
raises an error but returns #f on invalid input.
The second problem is that (finite? +nan.0) => #t. This is incompatible
with other Schemes that define this predicate as well as R6RS and the
R7RS draft. I've fixed this and added cases for it to the library tests.
This also caused issues in the conversion process in string->number when
used from READ. With this patch it says "illegal number syntax" with
a line number, before it just said "(inexact->exact) inexact number cannot
be represented as an exact number"
PS: shouldn't C_i_finitep actually be called C_u_i_finitep?
It's obviously unsafe (pass it any non-fixnum immediate and it'll
probably blow up).
Cheers,
Peter
--
http://sjamaan.ath.cx
--
"The process of preparing programs for a digital computer
is especially attractive, not only because it can be economically
and scientifically rewarding, but also because it can be an aesthetic
experience much like composing poetry or music."
-- Donald Knuth
0001-Add-a-few-more-number-syntax-tests-from-John-Cowan-a.patch
Description: Text document
- [Chicken-hackers] [PATCH] string->number shouldn't raise errors but return #f on failure,
Peter Bex <=