#1408 closed feature request (wontfix)
groupWhen – a groupBy that compares consecutive values
Reported by: | Owned by: | ||
---|---|---|---|
Priority: | normal | Milestone: | |
Component: | libraries/base | Version: | 7.0.2 |
Keywords: | Cc: | ghc@…, rturk@… | |
Operating System: | Unknown/Multiple | Architecture: | Unknown/Multiple |
Type of failure: | None/Unknown | Test Case: | |
Blocked By: | Blocking: | ||
Related Tickets: | Differential Rev(s): | ||
Wiki Page: |
Description
groupBy
has a minor problem: It always uses the first value of a group to decide whether a new value belongs to this group or the next. In several cases it would be more useful if it would take the last value of a group, thus always comparing consecutive values.
Example code:
groupWhen :: (a -> a -> Bool) -> [a] -> [[a]] groupWhen _ [] = [] groupWhen _ [a] = [[a]] groupWhen f (a:l) = if f a (head c) then (a:c):r else [a]:c:r where (c:r) = groupWhen f l
Uses:
groupWhen (\a b -> b - a < 5) [1,2,4,10,14,16,18] -- Finding holes in a increasing series, e.g. log time stamps (my real use case)
or
groupWhen (<) [1,2,3,2,10,12,10,11] -- Group into strictly increasing sublists
Note that for transitive and symetrical comparision functions f
(such as (==)
), groupBy f == groupWhen f
.
It should probably go to Data.List
Change History (11)
comment:1 Changed 13 years ago by
comment:2 Changed 13 years ago by
Component: | libraries (other) → libraries/base |
---|
The Haskell 98 Report (s17.6) says "When the By
function replaces an Eq
context by a binary predicate, the predicate is assumed to define an equivalence". Since the new function agrees with groupBy
in that case, I think it would be reasonable to redefine groupBy
as this more useful version.
The same applies to nubBy
, and possibly deleteBy
, deleteFirstsBy
and intersectBy
(which could have more general types to make this clear).
On the downside, it would mess up the simple uniform treatment of the By
functions.
comment:3 Changed 12 years ago by
Resolution: | → wontfix |
---|---|
Status: | new → closed |
I think that if we have both groupBy and this new function then the names should be more similar (I'd expect groupWhen to do something completely different), and if possible allude to the functionality difference.
Are there any cases when the existing behaviour is better?
No matter what, I think this should go via http://www.haskell.org/haskellwiki/Library_submissions so I'm closing this bug.
By the way, the hpaste link seems to now be about catching monkeys.
Thanks
Ian
comment:4 Changed 12 years ago by
I’m currently not interested enough to follow the complete procedure. Can’t you just reassign the bug somewhere appropriate, until someone picks it up?
comment:5 Changed 11 years ago by
Architecture: | Unknown → Unknown/Multiple |
---|
comment:6 Changed 11 years ago by
Operating System: | Unknown → Unknown/Multiple |
---|
comment:7 Changed 10 years ago by
difficulty: | Easy (1 hr) → Easy (less than 1 hour) |
---|
comment:8 Changed 9 years ago by
Cc: | ghc@… added |
---|---|
Type of failure: | → None/Unknown |
You may like to use my groupBy in: http://hackage.haskell.org/packages/archive/utility-ht/0.0.5.1/doc/html/Data-List-HT.html#v:groupBy
comment:9 Changed 9 years ago by
Version: | 6.6.1 → 7.0.2 |
---|
It seems to worry many people:
http://www.haskell.org/pipermail/haskell-cafe/2011-March/089832.html http://www.haskell.org/pipermail/libraries/2007-August/008039.html http://www.haskell.org/pipermail/haskell-cafe/2007-April/024971.html http://www.haskell.org/haskellwiki/List_function_suggestions#Generalize_groupBy_and_friends
comment:10 Changed 9 years ago by
Cc: | rturk@… added |
---|
comment:11 Changed 9 years ago by
I'ld like to add http://www.haskell.org/pipermail/libraries/2009-November/012794.html where such a function is called "runs".
More comments and other implementations on http://hpaste.org/141