The case for n-ary "if" in R7RS
Daphne Preston-Kendal <r7rs@dpk.io> -- 2013-04-06

---- HISTORICAL NOTE, 2021-11-15 ----
I wrote this page in 2013. While I continue to think that ‘if’ should work like
this in Lisp, and someone designing a new dialect of Lisp should make things
work the way described here, the ship sailed long ago for Scheme. I now think it
would be better to maintain the current situation with both ‘if’ and ‘cond’ as
distinct constructs.

The original argument is reproduced below.
-------------------------------------

The distinction between "cond" and "if" is a historical mistake which has
propagated thru variants of Lisp like wildfire. It is too late to abolish it in
Scheme, but amends can be made by adding new features to "if" to make it the
construct which "cond" always should have been.

Lisp 1 had COND in very much the form we know it today; but it had no implicit
progn, no else keyword, and no equivalent of the => construct. Without implicit
progn, it can easily be seen that the parentheses around each predicate/body
pair is wasteful clutter, and that, for example, (cond (a b) (c d)) could be
reduced to (cond a b c d). (Why did Lisp 1 have the parentheses? I don't know,
but I suspect the answer was related to them being hidden in "normal" use by
M-expressions. (John McCarthy also said he thought they were a mistake, which
perhaps validates this theory.))

The case against cond's implicit progn is quite simple: it encourages imperative
code; since most Scheme is functional, most uses of cond do not use more than
one consequent expression; therefore, the extra parentheses required in this
case are needless visual clutter.

Regrettably it is now too late to make this change to Scheme; but a simple
backwards-compatible change to the syntax and semantics of "if" will do just as
well.

The following semantics apply:

    (if)             ;=> an error / #f
    (if a)           ;=> an error / a
    (if a b)         ;=> (cond (a b))
    (if a b c)       ;=> (cond (a b) (else c))
    (if a b c d)     ;=> (cond (a b) (c d))
    (if a b c d e)   ;=> (cond (a b) (c d) (else e))
    ; etc.

The only feature of cond which this lacks (apart from implicit progn which, as
has been explained, is just as well or better done explicitly) is the possib-
ility of anaphora provided by the => keyword; cond is not going away, of course,
so if you need this, you can still use it. (There are perhaps better ways to
achieve it, but this proposal does not cover those.)