[racket] read of numbers with decimal point default to exact?

This is just a small idea, not something I'd argue for strongly...

How about making numbers formatted with decimal points, like "12.34", 
read as exact rather than inexact?

The rationale being: decimal point format is a commonplace and very 
useful format for writing exact rational numbers, and if one writes a 
number like "5.55", there is nothing except an old Scheme convention to 
imply that one intends "5.55" to be any less exact than "555/100".  (I'm 
ignoring any question of precision here, which Scheme does not address 
either.)

For example, with this change, the following expression would evaluate 
to an exact 5 rather than what it currently does: an inexact 
4.999999999999999.

(/ (read (open-input-string "5.55")) 1.11)

The exact 5 result would also be what I imagine is expected by, say, 
casual programmers using Racket for financial calculations, which I 
think would be a small selling point for Racket.

Python 2.5.2 (r252:60911, Jan 24 2010, 14:53:14)
[GCC 4.3.2] on linux2
Type "help", "copyright", "credits" or "license" for more information.
 >>> 5.55 / 1.11
4.9999999999999991

The only good linguistic argument I can think of against this is that, 
when we have Racket *write* (as in the "write" procedure, not "display") 
inexact rationals in decimal-point form, they'd need to be written with 
an "#i" prefix, so that inexactness is preserved on a *read* of that 
same format by Racket.  The drawbacks I see to the "#i" on write are 
small: (1) visually, it's a little bit more cluttered; (2) it will break 
any legacy code that assumes it can do a write of numbers for some 
interoperation or UI purpose that doesn't work if the "#i" prefix is 
added.  "#i" could even be considered helpful, as in a heads-up to the 
programmer that they have a number that might be corrupted by IEEE 
floating-point operations they didn't expect.

The only implementation efficiency argument I can think of against this 
is perhaps wanting numbers to be inexact by default, so that native 
floating-point representation and operations can be used more often.  If 
that is indeed a consideration, I'd prefer to leave adding "#i" prefixes 
and "exact->inexact" calls as optimizations that can be added 
consciously by programmers, with the default being more exact than 
efficient.

-- 
http://www.neilvandyke.org/