I noticed that http://clojure-examples.appspot.com/clojure.core/max has both
(apply max [1 2 3 4]) -> 4 and (max []) -> [] (which I think is a poor
example).

However, when attempting to add another example for (apply max []) which I
expected to return nil, that instead it throws an exception.

I have to admit, I've never come across this in practice, but it seems like
adding the overload would be nice for generality.

-- Aaron

Once you walk down the path of "What should (max) return?" I think you won't want a default behavior.

Stu

P.S. Agreed that (max []) is a bad example.

On Fri, 9 Jul 2010 13:57:05 -0400

Given that max only works on numbers, then why doesn't (max []) throw
the same exception as (max [] [])? Or, for that matter, (max \a) throw
the same exception as (max \a \b \c)?

If max worked on any comparable (which is what I expected), then (max
A) always returning A makes sense, even if A isn't comparable. But
that behavior when max is defined as only working on numbers sure
seems like a bug.

      <mike
--
Mike Meyer <m...@mired.org>           http://www.mired.org/consulting.html
Independent Network/Unix/Perforce consultant, email for more information.

O< ascii ribbon campaign - stop html mail - www.asciiribbon.org

Clojure tends not to guarantee any particular behavior for invalid
inputs.  It might return an error, or it might give back a spurious
answer.

Most likely, the code for max just has a case that if it is only
passed a single input, then that is the answer.  No error checking is
performed.