Re: [Chicken-hackers] [PATCH] Omit warning about exact fractions when asked for an inexact value

[Peter Bex]

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)
          (radix radix))
      (eqv? 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!

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