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
