Following up to my own post :-{, but after further communication with
Mike Gunter, a good example for why generalising some of the *By
functions List is a good idea was presented, namely that of
deleteFirstsBy
deleteFirstsBy :: (a -> a -> Bool) -> [a] -> [a] -> [a]
generalising it to
deleteFirstsBy :: (a -> b -> Bool) -> [a] -> [b] -> [a]
is genuinely useful, i.e.,
foo = deleteFirstsBy
(\ rec id -> id == personId rec)
list_of_records
list_of_ids_to_delete
So, if my first reply suggested otherwise, I'm positive to the
proposed generalisation of the *By functions:
deleteBy :: (a -> Bool) -> [a] -> [a]
deleteFirstsBy :: (a -> b -> Bool) -> [a] -> [b] -> [a]
notElemBy,elemBy :: (a -> Bool) -> [a] -> [a] -- or just stick with any?
lookupBy :: (a -> Bool) -> [(a,b)] -> Maybe b
maximumBy, minimumBy :: (a -> a -> Bool) -> [a] -> a
nubBy :: (a -> a -> Bool) -> [a] -> [a]
elemIndexBy :: (a -> Bool) -> [a] -> Int
groupBy :: (a -> a -> Bool) -> [a] -> [[a]]
(the second arg. to List's deleteBy, elemBy, notElemBy, lookupBy and
elemIndexBy have been applied to the predicate here - I'm not fussed
either way).
The benefit of `elemBy' over `any' still eludes me though, anyone
care to enlighten me :-)
--Sigbjorn
>
> From: Sigbjorn Finne <[EMAIL PROTECTED]>
> Date: Tue, 14 May 96 21:04:28 +0100
>
> >
> > I noticed that the *By functions (deleteBy, deleteFirstsBy, elemBy,
> > etc.) in the current on-line HTML library documentation have type signatures
> > which restrict the types beyond that required by the implementation.
> > For instance:
> >
> > elemBy, notElemBy :: (a -> a -> Bool) -> a -> [a] -> Bool
> > elemBy eq _ [] = False
> > elemBy eq x (y:ys) = x `eq` y || elemBy eq x ys
> >
> > My recollection is that when I brought this up last on this mailing
> > list, public input ran in favor of not restricting the type signature.
> > (For instance
> > elemBy, notElemBy :: (a -> b -> Bool) -> a -> [b] -> Bool
> > )
> >
>
> I'm probably missing the point of the (elemBy, notElemBy) pair
> alltogether, but why not just stick with `any'? i.e., of the
> two value bindings
>
> ls :: [HaskellImplementation]
> wibble = elemBy (inTheBallpark) 1.3 ls
> frob = any (inTheBallpark 1.3) ls
>
> `frob' is clearer than `wibble' - YMMV.
>
> What is the motivation for including {not}elemBy in List? If it is
> the wish to have 1-1 match of *By functions with PreludeList defns
> that uses type class predicates (from Eq and Ord) then elemBy should
> stay as is, and any uses of `non-standard' equality predicates (e.g.,
> a -> b -> Bool) are better coded up using `any', `filter' etc.,
> since the generalised predicate is not applicable to all *By functions
> (cf. deleteFirstsBy, nubBy).
>
> All IMHO, of course.
>
