##sys#string->number gets called without prefixes in the reader

[sjamaan]

Chicken core's reader calls ##sys#string->number on the number without the radix&exactness prefix.

This causes issues when for example you're reading something like the following: "#e1e500". The reader passes on "1.0e500" and then converts it to an exact number using inexact->exact, but that fails because flonums can't represent a number that large. I know it's probably a bit of an edge case, but this is more convenient input syntax than typing a 1 followed by 500 zeroes, which AFAIK is the only other way to enter an exact number like that.

Another approach would be to do like I now do in numbers trunk itself; string->number first analyses the prefix like Chicken core does, and then passes the radix *and* an extra argument indicating whether to force exactness (or inexactness?) to the procedure that handles the actual number parsing. This would be an easier fix, but I think this can't be done in a backwards-compatible way.

[felix winkelmann]

Attached is a patch which I believe might help here - it pushes the exactness conversion into ##sys#string->number, via an additional optional argument which is either #f (undetermined), the symbol 'i (inexact) or 'e (inexact). On older chickens, the third argument will always be false, so this should be backwards-compatible.

Is this useful?

We should also review the remaining hooks used in numbers (##sys#inexact?, ##sys#inexact->exact, ##sys#exact->inexact, etc.). Some of them might be redundant and allow us to optimize/rewrite core procedures in better ways.

[sjamaan]

This patch works; numbers now passes all its tests. It doesn't fix the reader accepting syntax like "#e#x#e10", but that's arguabling a separate problem.

I don't know about the hooks. The complete list of hooks being used is:

##sys#number->string
##sys#string->number
##sys#number?
##sys#integer?
##sys#exact?
##sys#inexact?
##sys#inexact->exact
##sys#exact->inexact

I tried removing them, but this causes the tests to fail; apparently because the "test" egg is using inexact? and number? to check if the expression results in a flonum or a fixnum. It just happens to work because it's not really relying on the number type otherwise.

Also, the core system itself relies on number? being hooked to dispatch when printing an object (it shows #<bignum> when printing a bignum when number? isn't hooked. I could of course define a record printer for bignums, ratnums and compnums instead, but who knows what else relies on number? returning #t for all numbers?)

I don't know about the others, but I expect similar hairy issues to arise when we just rip them out.

[felix winkelmann]

Can this ticket be closed?

[sjamaan]

Yep, doing so. Thanks for implementing this!