Draft 6 says that it's an error for an argument of / (other than the first) to be an exact zero. R6RS, however, says that it's an error only if *all* the arguments are exact. In other words, (/ 2.0 0) is an error according to the draft, but in R6RS it returns +inf.0 (assuming the implementation supports it). The proposal is to adopt the R6RS wording.

I tested (/ 2.0 0) in the usual set of Schemes:

- Racket, Gambit, Chicken (with the numbers egg), Guile, Chibi, Elk, Spark report an error.
- Gauche, Bigloo, Scheme48/scsh, Kawa, SISC, Chez, SCM, Ikarus/Vicare, Larceny, Ypsilon, Mosh, IronScheme, NexJ, STklos, RScheme, BDC, UMB, VX return +inf.0.
- MIT, scsh, Shoe, TinyScheme, Scheme 7, XLisp, Rep, Schemik, Inlab always report an error when dividing by zero, exact or inexact.
- KSi, Scheme 9 produce incorrect results.
- SigScheme, Dream, Oaklisp, Owl Lisp don't support inexact numbers.

statusnewdecided

WG1 decided to make no change, keeping the R5RS rules.

resolution␣wontfix

statusdecidedclosed

Here is a Galilean dialogue between Sixer, a proponent of the R6RS rule, and Fiver, a proponent of the R5RS rule, which is the same as that of R7RS draft 6.

Sixer: Why shouldn't / should do inexact contagion, just like the other arithmetic operations?

Fiver: Because an inexact operation may return an exact result if it can prove that the inexactness can't affect the result, like (* 1.0 0) returning 0 rather than 0.0.

Sixer: Certainly. But what has that to do with it?

Fiver: Dividing by exact 0 doesn't care about the inexactness of the other arguments. There is no exact infinity in Scheme, so it's more appropriate to report an error representing the non-existent value. Since we don't require errors to be signalled except in a few circumstances, "is an error" is the appropriate phrase.

Sixer: The value +inf.0 can be understood as covering both overflow and positive affine infinity. Surely that's the least surprising result when inexact numbers are involved?

Fiver: But why should the result of dividing by an exact 0 be positive rather than negative? Zero, after all, is neither.

Sixer: I don't know, man, I didn't do it, but IEEE 754 says so.

Fiver: Well, anyway, "is an error" covers both raising an exception and returning +inf.0.

Sixer: True, but numerical programmers expect to be able to rely on the IEEE rules, instead of the bad old days when division by zero always crashed your program.

Fiver: Then let them avoid exact numbers.

Sixer: Maybe. Is that realistic? I don't know.

Fiver: Me either.