Specifications of 'any', 'all', 'findIndices'

[Jerzy Karczmarczuk]

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.
> Hannah.

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? 

Jerzy Karczmarczuk
Caen, France

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).