Alistair, I agree with Mike Gunter on this one. -- P
> Mike Gunter writes:
> The ____By functions in the 1.3 PreludeList (elemBy, deleteBy, etc.)
> all take ``equality'' predicates with type a -> a -> Bool. Most of
> these functions (with no change in definition that I see in a quick
> check) could take predicates with type a -> b > Bool (with a
> corresponding change in the type of the other arguments). For
> example, I find myself wanting to use
> elemBy :: (a -> b -> Bool) -> a -> [b] -> Bool
> elemBy = any (eq x)
> while the draft prelude has
> elemBy :: (a -> a -> Bool) -> a -> [a] -> Bool
> elemBy = any (eq x)
>
> The one downside that I can see (I've not thought about this long) of
> such a generalization is a few problems (caught during type-checking)
> when one forgets which predicate argument comes from the key and which
> from the list. What are the others?
>
> I thought briefly of doing this but decided against it for several
> reasons. These are weak and somewhat interconnected - so they may
> well yield to a few minutes intelligent thought (sadly, I'm incapable
> of intelligent thought at the moment - I can't get to the coffee shop
> for the snow and Yale coffee is undrinkable).
>
> 1) The less general signature makes it a simple generalisation of the
> existing functions. In particular, if Haskell allowed these type
> synonyms, we could have:
>
> type Eq a = a -> a -> Bool -- illegal: can't use same name for
> type Ord a = a -> a -> Bool -- type and class
>
> elem :: Eq a => a -> [a] -> Bool
> elemBy :: Eq a -> a -> [a] -> Bool
>
> 2) The semantics of these functions is somewhat subtle (ie tedious to
> informally state/remember) if the predicate is not an equivalence.
> Allowing the more general signatures encourages use of non-equivalences.
>
> 3) Where an equivalence is not being used (eg every time the predicate
> has most general type "a -> b -> Bool"), a name like "elemBy" doesn't
> really capture what is going on.
>
> The obvious fix is of course to come up with better names - but what??
>
> And, once we've provided the more general versions with different
> names, should we throw in the elemBy, deleteBy, etc anyway for
> consistency with nubBy and friends?
>
> [Incidentally, the current mood of the Haskell committee seems to be
> to put these in libraries as part of an (often ignored) effort to slim
> Haskell down - or at least reduce its rate of growth.]
>
> Alastair Reid
> Yale Haskell Project
