better elif

[gilch]

Related to #713, and possibly #760. We should prefer Clojure forms over Common Lisp's. Can we leave out the extra brackets in cond?

; Common Lisp cond
(cond ((= x 42) "perfect")
      ((> x 42) "greater"))
      ("default"))

Clojure doesn't have them:

; Clojure cond
(cond (= x 42) "perfect"
      (> x 42) "greater")
      :else "default")

; Hy
(cond [(= x 42) "perfect"]
      [(> x 42) "greater"]
      [True "default"])

I would rather use an explicit do/progn in the less common case that I need one, than have to type the extra brackets every single time.

This would, of course, break existing Hy code. If that's unacceptable, I have an alternative suggestion--extend the if form to accept more than three arguments:

(if (= x 42) "perfect"
    (> x 42) "greater"
    "default")

Arc Lisp's if actually works this way.
(tl;dr --- here's the relevant excerpts from the link above:)

An if with more than three arguments is equivalent to a nested if.  

(if a b c d e)

is equivalent to

(if a
    b
    (if c
        d
        e))

If you're used to languages with elseif, this pattern will be
familiar. [1]

Notes

[1] Note to Lisp hackers: If you're used to the conventional Lisp
cond operator, this if amounts to the same thing, but with fewer
parentheses.  E.g.

(cond (a b)
      (c d)
      (t e))

becomes

(if a b
    c d
      e)

JMC's original cond didn't have implicit progn, so the parens around
each pair of clauses were unnecessary.  They became necessary soon
after, however, when cond started to have implicit progn in the
first Lisp implementations.  This probably prevented people from
realizing they hadn't originally been needed.  But most conds in
the wild seem to occur in purely functional code, and thus pay the
cost in parens of implicit progn without actually needing it.  My
experience so far suggests it's a net win to offer progn a la carte
instead of combining it with the default conditional operator.
Having to use explicit dos may even be an advantage, because it
calls attention to nonfunctional code.
...