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

[Eric Shade]

I have some questions about the specifications of 'any', 'all', and
'findIndices' in the Haskell 98 reports.  The specifications of 'any'
and 'all' are

    any p = or . map p
    all p = and . map p

While this is correct, it seems to me that it generates a lot of
garbage because map will produce a list of Booleans until 'any' sees a
True or 'all' sees a False.  'elem' and 'notElem' inherit the problem
because they're defined in terms of 'any' and 'all'.  I realize that
this is only a specification, but Hugs at least uses this as its
implementation.  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

leave 'elem' and 'notElem' as is, then define

    and = notElem False
    or  = elem True

There is a similar problem with findIndices, whose specification is

    findIndices p xs = [i | (x,i) <- zip xs [0..], p x]

While this is admittedly cool, it also seems to generate a lot of
garbage by producing pairs only to throw them away.

I'm not yet up to speed on the implementation of lazy functional
languages, so it may be that in all of these cases the compiler can
easily optimize away the garbage.  If so, it would be nice to see some
documentation for non-wizards that explains what kinds of
optimizations one can reasonably expect (like tail-recursion
elimination in Scheme).

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.

-- 
Dr. Eric Shade, Associate Professor
Computer Science Department (CSAB Accredited)
Southwest Missouri State University