This page is part of the web mail archives of SRFI 77 from before July 7th, 2015. The new archives for SRFI 77 contain all messages, not just those from before July 7th, 2015.
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.