Opened 10 years ago

Closed 10 years ago

#674 closed defect (fixed)

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

Reported by: sjamaan Owned by: felix winkelmann
Priority: major Milestone:
Component: core libraries Version: 4.7.x
Keywords: reader, numbers Cc:
Estimated difficulty:

Description

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.

Attachments (1)

push-exactness-into-hook.diff (3.9 KB) - added by felix winkelmann 10 years ago.

Download all attachments as: .zip

Change History (5)

comment:1 Changed 10 years ago by 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.

Changed 10 years ago by felix winkelmann

comment:2 Changed 10 years ago by 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.

comment:3 Changed 10 years ago by felix winkelmann

Milestone: 4.8.0

Can this ticket be closed?

comment:4 Changed 10 years ago by sjamaan

Resolution: fixed
Status: newclosed

Yep, doing so. Thanks for implementing this!

Note: See TracTickets for help on using tickets.