Contagious Inexactness: dealing with conditionals

[Andrew Wilcox <awilcox@xxxxxxxxxxxxxxxxx>]

How do we want to handle conditionals that don't just return one value
or another, but choose whether to perform an action?

    (if (< x y)
        (display "Not there yet.")
        (display "We've arrived!"))

    (call/cc (lambda (return)
               (if (< x y)
                   (return 'yes)
                   (return 'no))))

In my original proposal, the inexactness flag of the boolean returned
by < would be ignored in both examples.

[Egner et al. 2004] points out that having (< X Y) return an exact
result is "especially pernicious given that comparisons are one place
where the inaccuracies of floating-point numbers may really hurt."

Given that we often use a comparison to choose one action over
another, it seems equally pernicious to ignore the inexactness
information at the conditional.

Another option would be to require that the first argument of IF must
be an exact value.  The above examples would then signal an error if <
returned an inexact boolean.

When using approximate operations, the programmer would need to
explicitly choose how to handle the comparison: whether it is OK at
this point in the program to ignore inaccuracies, or do you need to
treat a range of values as being close enough, and so on.

In my original proposal, many different kinds of values could become
flagged as inexact: A string or a symbol, for example, could become
inexact if returned from an IF form.  In this new approach there is no
longer any way to construct inexact strings or symbols.

This more modest proposal extends inexactness to booleans, but
not to other types.  Much like R5RS forbids using an inexact integer
as the index argument for procedures such as LIST-REF, we would
forbid using inexact booleans as the test argument to conditionals.