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]







Reply via email to