Specifications of 'any', 'all', 'findIndices'
Tue, 23 Jan 2001 09:50:37 +0000
Hannah Schroeter wrote:
> Eric Shade wrote:
> > I have some questions about the specifications of 'any', 'all', and
> > 'findIndices'
> > any p = or . map p
> > all p = and . map p
> > ...It seems clearer and more efficient to me to use the
> > following definitions:
> > any p  = False
> > any p (x:xs) = p x || any p xs
> > all p  = True
> > all p (x:xs) = p x && all p xs
> > Even if the apparent inefficiencies melt away, I think that my
> > versions of 'any', 'all', 'and', and 'or' are clearer as
> > specification
> > than the current ones.
> I don't think so. The specifications are quite concise.
Just a moment, please. Do we speak about "concise" or "clear"?
Johannes Waldman makes the same fusion, first saying that it
is concise, and terminating with a statement on clear programming.
Personally I am a convinced lazy programmer, I adore concise
and obfuscated style, and I used with some internal pleasure the
original definitions, until I started using Haskell for teaching.
(I do not teach Haskell, we *use* it on compilation stuff, some-
times on some graphics projects, and they have to learn it
"off-line".) THREE TIMES I've been asked about that. Somebody
quite clever remarked that any or all are *typical* cases for
fold rather than for map.
There is plenty of historical accidents in the standard prelude.
[I won't complain any more about the Num stuff...]
Johannes Waldmann last sentence:
> Who said this, "premature optimization is the root of all evil".
Who said that what Eric Shade proposes is an evil optimization,
while a curried "pearl": "any p = or . map p" is a nice shorthand,
plenty of vitamines, especially for beginners.
BTW., why not promote something like
any = (or .) . map
to make everybody happy?
PS. Johannes Waldman raises some doubts:
> so it's not at all clear that the above implementation
> is indeed more efficient.
Please, don't speculate. If you have something to say in this
context, perform some tests. I did it with Hugs. Eric Shade
implementation seems to be indeed more efficient, but very
slightly (on my test, I won't claim anything general).