On Fri, 10 Oct 1997 [EMAIL PROTECTED] wrote:
> ? groupBy (<=) [1,2,3,4,5,1,2,3] == [[1, 2, 3, 4, 5, 1, 2, 3]]
>
> What I want to know is whether the members of the mailing list thing
> this is the right behaviour for groupBy.
I think that the utility of separating a list into runs satisfying a user
specified function would be very useful and ought to be added to the List
library. However, it ought to be a new function, since rewriting groupBy
would change the convention that a `By' prefix replaces a type class
constraint into a user specified function. (In this case an Eq a
constraint becomes a user specified equivalence relation. It's revealing
that the defintion goes `groupBy eq ...' rather than `groupBy op ...'.)
Perhaps `ascendingRuns' (with type constraint Ord a) and `ascendingRunsBy'
(with a reflexive, non-symmetric, transitive function) are candidates,
although the names are a bit long.
Incidentally, there is another way of generalising a type constrained
function which I think would also be useful, namely instead allowing a
projection function, e.g., as in
groupWithProjection :: (Eq b) => (a->b) -> [a] -> [[a]]
groupWithProjection proj = groupBy (\x y->proj x == proj y)
This approach would be useful when operating on a list whose items are
part key and part other data (where a prior `map proj' would just throw
away the other data part which would be needed later). It's easy enough to
write explicit lambda abstractions but it's rather messy compared to
abstracting away the actual application of the projection function at all
the relevant places. Perhaps I'm missing something and there's a nicer way
to do this using only existing library facilities?)
david tweed
------------------------------------------------------------------------
rm 2.01, Merchant Venturers Bldg "... we think mathematics is fun and
http://www.cs.bris.ac.uk/~tweed/ we aren't ashamed to admit the fact."
work tel: (0117) 9545104 -- Knuth, Graham & Patashnik
