On Wed, Jan 4, 2017 at 1:46 AM, Alex Shinn <xxxxxx@gmail.com> wrote:

I really think case-lambda is the biggest wart in R7RS,
and needs to be discouraged at every opportunity.

Per contra, I think it is one of the best additions to R5RS.
 
 1. it's more verbose for simple cases than other idioms
    for optional argument handling (DSSSL, let-optionals, etc.)

Yes, but it is clearer than any of them, and allows more flexibility
than they do, as in the case of atan, whose argument structure
([y] x) can't be written with DSSSL at all.
 
2. it's quadratic in code size for optional argument handling

If naively implemented, yes.
 
3. it encourages different behavior based on the number of
    arguments, which is extremely confusing for anything
    other than the most common functions (+, /, etc.)

Eh.  The first Lisp I ever used implemented - with right-to-left
association, and I still think that's better -- it makes (- x) not a
special case.   These things are a matter of getting used to them.
 
4. it's insufficient for meaningful variadic matching, such as
    dispatch closures, which could easily be handled by
    more general utilities such as match-lambda

I agree that we need a general matcher, but even Haskell has
some syntactic sugar over its general matcher for easy cases.
 
5. it encourages implementors to prematurely optimize,
    treating it as a core form, complicating their ASTs and
    associated utilities and all compiler transformations

As Marc N points out, it's almost as easy to treat case-lambda as
fundamental and lambda as a special case of it.

In hindsight, I wish we had standardized on case-define instead.
The trouble with

(define foo
  (case-lambda
    ((x) <some-complex-computation>)
    ((x y) (do-something! y) (foo x))))

is that do-something! might reassign foo, and consequently you can't
optimize by jumping straight into the single-argument case.  (Or can you?)
If we defined

(case-define foo
  ((x) <some-complex-computation>)
  ((x y) (do-something! y) (foo x)))

in suitable terms to bind foo within the clauses as well as after them,
we wouldn't have a problem.

I agree that non-top-level cond-expand is a wart, and I think that
non-top-level include is potentially a wart too, except that I hope
nobody thinks include is processed hygienically.  These things
should be done in the module language or at the very start of a
program as a matter of style.

-- 
John Cowan          http://vrici.lojban.org/~cowan        xxxxxx@ccil.org
The present impossibility of giving a scientific explanation is no proof
that there is no scientific explanation. The unexplained is not to be
identified with the unexplainable, and the strange and extraordinary
nature of a fact is not a justification for attributing it to powers
above nature.  --The Catholic Encyclopedia, s.v. "telepathy" (1913)