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

[Peter Bex]

On Fri, Mar 23, 2012 at 12:16:00AM -0400, John Cowan wrote:
> Peter Bex scripsit:
> 
> > According to the R7RS BNF, #e+inf.0 is actually valid numerical syntax,
> 
> Yes, you're right.  I shouldn't have said "syntax error".
> 
> > 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".
> 
> In all my Schemes in which reading #e+inf.0 raises an error, using
> string->number returns #f.  Only ones where #e+inf.0 returns +inf.0
> do otherwise.

Thanks for the info.  I've improved the "numbers" test suite (which I'd
like to remind everone can also be used for testing other R5RS Schemes,
and for R8RS Schemes if the tests for padding syntax are removed) to
include these cases:
http://bugs.call-cc.org/browser/release/4/numbers/trunk/tests/string-conversion.scm

One question though: what is (string->number "#i1/0") supposed to return?
I think +inf.0 is sane, but you could probably also make a case for #f.

Suggestion:  Improve the wording in string->number's description from

"If string is not a syntactically valid notation for a number,
 string->number returns #f"

to something like:

"If string is not a syntactically valid notation for a number or it
 would not result in a valid number, string->number returns #f"

(improvements are welcome, I know this sentence isn't great)

I'd also like to suggest adding the same line to the end that was in R6RS:

"Note:   The string->number procedure always returns a number
  object or #f; it never raises an exception."

This removes all doubt.  Adding these to the examples might also be useful:

"#e+inf.0" => #f
"#i+inf.0" => +inf.0
"1/0" => #f

The final example is also common behavior.  If "#i1/0" is specified, adding
an appropriate example for it is also a good idea, I think.

> > But when you realize (eqv? +nan.0 +nan.0) is unspecified (section 6.1),
> 
> I wouldn't assume that's stable.

I don't understand what you mean by that.  Since we now have a nan?
predicate, why not simply improve the code to the following?

(let ((number number)
      (radix radix)
      (number2 (string->number (number->string number radix) radix)))
  (or (and (nan? number) number2 (nan? number2))
      (eqv? number number2)))

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