Michael Marte <[EMAIL PROTECTED]> writes on
30 May 2000
> Standard module List defines:
> [..]
> groupBy :: (a -> a -> Bool) -> [a] -> [[a]]
> groupBy eq [] = []
> groupBy eq (x:xs) = (x:ys) : groupBy eq zs
> where (ys,zs) = span (eq x) xs
>
> In my programs, I often use the following function to compute
> equivalence classes:
>
> eqClasses :: Eq a => [a] -> [[a]]
> eqClasses = eqClassesBy (==)
> [..]
>
> There is a single difference: The use of span vs. partition, i.e.
> grouping and computing equivalence classes are very similiar. Indeed,
> if a set is represented by a sorted list, grouping can be used to
> compute its equivalence classes efficiently.
I think, some standard functions need additional argument for the Mode.
This is for the economy of the function names: less interface names.
This is a common practice of options in programming.
For example,
partition :: Char -> (a -> Bool) -> [a] -> ([a],[a])
groupBy :: Char -> (a -> a -> Bool) -> [a] -> [[a]]
sort(By) :: Char -> ...
find :: Integer -> ...
`partition' could behave as `span' under certain mode.
So, `span' removes.
groupBy could split to the equivalence classes under the
appropriate mode.
sort(By) could apply different algorithms: quickSort,mergeSort,...
depending on the mode 'q', 'm' ...
In many situations, the Mode helps the efficiency that points
whether the list is ordered, or whether it contains repetitions (by
equivalence).
A joke: use Mode :: String to obtain unique program for each type.
Generally, the functions have to unify that have common philosophy and
tradition, not only common type.
------------------
Sergey Mechveliani
[EMAIL PROTECTED]