[R6RS] quotient, remainder, modulo

[William D Clinger]

Mike wrote:
> Excutive summary:
> 
> - Extend `quotient' and `remainder' to arbitrary reals and make their
>   description consistent with that of `div' and `mod'.
> 
> - Ditch `modulo'.

This is Mike's summary of the position he advocates,
but is not an accurate summary of the SRFI 77 discussion.
In this note I will be arguing against Mike's position.

> Now, `quotient+remainder' could be described in the same way.  In
> fact, the Scheme code from R5RS reproduced in the SRFI represents the
> same equation.  I propose that we do this, thus generalizing
> `quotient+remainder' to arbitrary reals, just like `div+mod' and
> `div0+mod0'.

The argument against quotient+remainder was stated quite well
by Egner, Kelsey, and Sperber in their paper presented at the
2004 Scheme workshop.  The latest draft of SRFI 77 cites this
paper as the rationale for div+mod:

    Rationale: These operations generalize integer division to
    real numbers.  Even with integer arguments, they are better
    suited than quotient and remainder to implement modular
    reduction [Egner et al. 2004].

I and virtually everyone else has found this particular rationale
convincing.  (The original statement of the rationale was flawed,
but that's irrelevant now.)  Everyone agrees that our traditional
specification of quotient/remainder/modulo was a mistake.  Why
should we generalize that mistake?

> The way the characterization is written provides the rationale why
> `div' is paired with `mod', `div0' is paired with `mod0', and
> `quotient' is paired with `remainder'.  However, `modulo' has no dance
> partner, and its usefulness is questionable---I've certainly never
> seen a case where it was exactly the right thing and none of the
> other three was.

I have encountered several situations in which modulo was more
the right thing than remainder, but I too have never encountered
a situation in which modulo was more the right thing than the mod
procedure of SRFI 77, as specified in the latest draft.

> As the issue isn't complicated but confusing, I
> suggest relegating `modulo' to the R5RS compatibility library and
> getting rid of it for the regular R6RS.

I agree with this.  I believe we should do the same with quotient
and remainder:

> Will argued for ditching `quotient' and `remainder' as well (as did
> Sebastian Egner):
> 
> http://srfi.schemers.org/srfi-77/mail-archive/msg00420.html
> 
> However, Brad Lucier argues that we should keep `quotient' here:
> 
> http://srfi.schemers.org/srfi-77/mail-archive/msg00424.html

The only explicit rationale that Brad gave for keeping quotient is
that it "is a natural operator for those who've been taught long
division in school".  While I believe this rationale would be well
served by banishing quotient and remainder to the R5RS compatibility
library, I do not object to keeping them for the R6RS, as proposed
by SRFI 77 in both its original and revised forms.

I do object, however, to the generalization of quotient, remainder,
and modulo to apply to arbitrary reals.  I believe we should regard
these as deprecated procedures, preserved primarily for compatibility
with the R5RS, and should encourage the use of div+mod in new code.
To the extent that quotient, remainder, and modulo would still serve
any purpose in the R6RS, it would be as integer-only procedures that
coincide with div+mod on non-negative integers, which is useful when
a programmer wishes to express that the arguments and results of
these procedures should always be integers.

> He also argues for providing a dance partner for `modulo', but no
> explicit rationale.

Brad also said he is "open to considering other options" for modulo,
and I believe he would accept the mod procedure, as now specified by
the latest draft of SRFI 77, as a replacement for modulo.  Brad's
objections to the original specification of mod do not apply to mod
as specified in the latest draft of SRFI 77.  Brad has not yet seen
that draft.

Will