[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Scheme-reports] [Chicken-hackers] [PATCH] Omit warning about exact fractions when asked for an inexact value
- To: chicken-hackers <chicken-hackers@x>
- Subject: Re: [Scheme-reports] [Chicken-hackers] [PATCH] Omit warning about exact fractions when asked for an inexact value
- From: Peter Bex <Peter.Bex@x>
- Date: Thu, 22 Mar 2012 21:01:57 +0100
- Cc: Scheme Reports <scheme-reports@x>
- In-reply-to: <20120322151406.GC19410@frohike.homeunix.org>
- Mail-followup-to: chicken-hackers <chicken-hackers@x>, Scheme Reports <scheme-reports@x>
- References: <20120321213554.GK882@frohike.homeunix.org> <20120321221305.GC10202@mercury.ccil.org> <20120322114842.GA19410@frohike.homeunix.org> <20120322141310.GB21494@mercury.ccil.org> <20120322142452.GB19410@frohike.homeunix.org> <20120322150530.GD21494@mercury.ccil.org> <20120322151406.GC19410@frohike.homeunix.org>
On Thu, Mar 22, 2012 at 04:14:06PM +0100, Peter Bex wrote:
> On Thu, Mar 22, 2012 at 11:05:30AM -0400, John Cowan wrote:
> > The only remaining problem [with the "numbers" Chicken egg] I'm
> > seeing is that #e+inf.0, #e-inf.0, #e+nan.0, #e-nan.0 return inexact
> > numbers instead of reporting a syntax error. This is minor.
> Thanks for pointing that out. I will fix this tonight and add a test.
I had a look but I'm afraid this opens a new can of worms :(
According to the R7RS BNF, #e+inf.0 is actually valid numerical syntax,
by following the rules
<num R> => <prefix R> <complex R>
<prefix R> => #e, <complex R> => <real R>
<real R> => <infinity>
<infinity> => +inf.0 (or +nan.0, -inf.0, your other examples)
Chicken reports an error during read. This is not a syntax error
but a type error, (exn type) to be precise. It also raises this
when using string->number, not just when READing from a port.
It's unclear to me whether (string->number "#e+inf.0") should
return #f or raise an error. The syntax is valid, but the question
is nonsense: "give me an exact value of infinity".
The text of the standard for string->number (6.2.7) or the lexical
structure (7.1.1) doesn't give any guidance on what to do, either.
There's a glimmer of hope in one paragraph in 6.2.7, where it says
"The procedure number->string takes a number and a radix and returns
as a string an external representation of the given number in
the given radix such that
(let ((number number)
(string->number (number->string number radix) radix)))
is true. It is an error if no possible result makes this expression true".
But when you realize (eqv? +nan.0 +nan.0) is unspecified (section 6.1),
this sentence actually seems to indicate that you might not be able to
read and/or write NaN values. The R5RS specification of eqv? is at least
clear that (eqv? +nan.0 +nan.0) => #f (because they're both numbers which
aren't "=" to eachother), and there it should probably really *be* an
error in the strictest reading of that standard.
Additionally, both say that number->string must be implemented in such a
way that this code returns true, but they don't put any similar
restrictions on string->number. That's odd!
"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
Scheme-reports mailing list