[racket-dev] flonum vs. inexact-real

At Sun, 3 Oct 2010 11:24:54 -0400, Sam Tobin-Hochstadt wrote:
> On Sun, Oct 3, 2010 at 10:42 AM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> > The `flonum?' predicate would be the only new predicate for now. The
> > `inexact-integer?' predicate would imply `flonum?', but not vice-versa.
> 
> I assume you mean `inexact-real?' here.
> 
> > The flonum operators (with names that start `fl' or `unsafe-fl') would
> > require and produce flonums, only.
> 
> I worry that this is a hazard for existing code.  For example, this
> plain Racket code:
> 
> (define/contract (f x)
>   (inexact-real? . -> . inexact-real?)
>   (unsafe-fl+ x 3.2))
> 
> goes from being a safe optimization to potentially segfaulting.

I imagined that there would be some time between introducing `flonum?'
and enabling 32-bit floats. During that in-between time, both `flonum?'
and `inexact-real?' would be ok in practice, but code should migrate to
`flonum?'.

> Similarly (but less bad), this Typed Racket code:
> 
> (: f : Any -> Float)
> (define (f x)
>   (if (inexact-real? x)
>       (fl+ x 3.2)
>       0.0))
> 
> which currently typechecks would now be a type error.

I didn't really consider the transition for Typed Racket. Would a grace
period similar to the dynamic case be possible and worthwhile (where
`inexact-real?' is treated like `flonum?' for a while longer, but
`flonum?' also becomes available)?

> I don't know how much we should worry about this, but we should
> probably worry at least a little.

Yes. Floating-point support isn't really what I prefer to think about
right now, but if we want to change, it would be better to change
earlier rather than later. Whether it's still early enough to be
usefully "earlier" is a key question.

Overall, I'm leaning in favor of the change.