Re: [Haskell-cafe] rolling span and groupBy for lists

On 5 February 2018 at 12:22, Evan Laforge
I have my own list library with a bunch of things like this. I think it's what most people do, and some upload them to hackage, e.g. utility-ht or the split package, or data-ordlist.
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own. And then uploading what you wrote to hackage compounds the problem. A hoogle search only shows the groupBy in base, signature search also does not yield other results, it seems hoogle does not cover those other packages. After writing my own and spending quite a bit of time I could find two other similar implementations of groupBy, one in "utility-ht" package and the other in "data-list-sequences" but they don't turn up in hoogle search. It looks like hoogle database should cover more packages, or maybe the search has some issues. This state of affairs encourages people to write their own rather than find and reuse stuff. My example in this email can be dismissed as a small one but I think it is a larger problem.
You can probably find something like this in 'split', or if not, that might be a good place to contribute it.
Yes, that is the fallback option I was considering, split seems to be the most comprehensive of all such list related packages.
I have a bunch of grouping functions too, which I use all the time, so if there's some kind of general list grouping package then maybe I could put them there.
It will be a great service to other Haskell explorers if we can consolidate all such packages and make one standard package covering most use cases and deprecate the other packages. Also it may be a good idea to have a see-also or related packages kind of field in packages so that discovery is easy.
On the other hand, this sort of thing is pretty individual, so it doesn't seem so bad for each person to have their own local library. That way you know it fits your style. Ultimately I think that's why none of the split functions made it into Data.List, every person has a slightly different idea of what it should be.
I thought that rollingGroupBy would have been a better default option as it can practically subsume the purpose of groupBy. groupBy in base is not well documented, and intuitively many think it works the way rollingGroupBy works i.e. compare two successive elements rather than comparing a fixed element. See this stack overflow question https://stackoverflow.com/questions/45654216/haskell-groupby-function-how-ex... , I thought the same way. I guess if we compare two successive elements, by transitive equality the existing groupBy implementation will practically get covered by that, not strictly compatible but should serve all practical purposes. That was the point why I was asking to consider having it in base alongside groupBy. It seems more useful, general and intuitive than the existing groupBy. -harendra
Hi,
For a small problem, I was looking for a groupBy like function that groups based on a predicate on successive elements but I could not find one. I wrote these little functions for that purpose:
-- | Like span, but with a predicate that compares two successive elements. The -- span ends when the two successive elements do not satisfy the
rollingSpan :: (a -> a -> Bool) -> [a] -> ([a], [a]) rollingSpan _ xs@[] = (xs, xs) rollingSpan _ xs@[_] = (xs, []) rollingSpan p (x1:xs@(x2:_)) | p x1 x2 = let (ys, zs) = rollingSpan p xs in (x1 : ys, zs) | otherwise = ([x1], xs)
-- | Like 'groupBy' but with a predicate that compares two successive elements. -- A group ends when two successive elements do not satisfy the
rollingGroupBy :: (a -> a -> Bool) -> [a] -> [[a]] rollingGroupBy _ [] = [] rollingGroupBy cmp xs = let (ys, zs) = rollingSpan cmp xs in ys : rollingGroupBy cmp zs
Are there any existing functions that serve this purpose or is there any simpler way to achieve such functionality? If not, where is the right
On Sun, Feb 4, 2018 at 7:50 PM, Harendra Kumar
wrote: predicate. predicate. place for these, if any. Can they be included in Data.List in base?
Thanks, Harendra
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Hello Harendra, Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations: http://hayoo.fh-wedel.de/?query=groupBy utility-ht shows up. -- Sergiu

Yes, Hayoo seems to be giving better results, I found more variants having
the behavior I want, it seems this variant is quite popular but still not
in any standard libraries.
Interestingly the problem of too many choices and no standard one that can
be discovered applies to search engines as well. In this case there are
only two choices but still it is of the same nature. I knew about hayoo but
forgot to use it in this case. How much time should one spend on finding a
trivial function before giving up and making the choice to write their own?
I wish there was a standard, quick, good quality way of discovering what to
use. It seems the Haskell ecosystem DNA encourages more and more
fragmentation rather than consolidation. I think the community/leaders
should acknowledge this problem and work on making things better in the
short/long run.
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu

Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100):
Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries.
Interestingly the problem of too many choices and no standard one that can be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write their own? I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in the short/long run.
A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort in this direction, has been recently announced: https://github.com/haskell/ecosystem-proposals/pull/4 You may want to contribute to the discussion. -- Sergiu
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
wrote: Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes more time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu
-- Sergiu

On 6 February 2018 at 00:33, Sergiu Ivanov
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100):
Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries.
Interestingly the problem of too many choices and no standard one that can be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write their own? I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in the short/long run.
A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort in this direction, has been recently announced:
Unfortunately, in my opinion, SLURP is taking things exactly in the opposite direction. I was talking about the problem of choice above and SLURP is giving even more choices and therefore encouraging more fragmentation. We should have just one good choice to stop wasting time and energy finding the best choice among millions available. Everyone should focus on making that one choice better rather spending energy in creating their own alternatives. This is where the Haskell ecosystem philosophy differs, it provides many choices in all aspects, it may be good in some cases but not always. SLURP is a technology solution which exactly fits in the same DNA. Technology can help us achieve the tasks that we set out to do but technology cannot motivate and influence us in what we choose to do and therefore ti cannot make the community focus on one goal - that requires real people leadership. If we do not focus on one goal, even with the best technology we may not succeed. Just my 2 cents. -harendra
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
wrote: Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes
more
time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu
-- Sergiu

We have two groups of "leaders", with partially opposing goals. This is a
disaster looking for an excuse to happen.
On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar
On 6 February 2018 at 00:33, Sergiu Ivanov
wrote: Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100):
Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries.
Interestingly the problem of too many choices and no standard one that can be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write their own? I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in the short/long run.
A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort in this direction, has been recently announced:
Unfortunately, in my opinion, SLURP is taking things exactly in the opposite direction. I was talking about the problem of choice above and SLURP is giving even more choices and therefore encouraging more fragmentation. We should have just one good choice to stop wasting time and energy finding the best choice among millions available. Everyone should focus on making that one choice better rather spending energy in creating their own alternatives. This is where the Haskell ecosystem philosophy differs, it provides many choices in all aspects, it may be good in some cases but not always. SLURP is a technology solution which exactly fits in the same DNA. Technology can help us achieve the tasks that we set out to do but technology cannot motivate and influence us in what we choose to do and therefore ti cannot make the community focus on one goal - that requires real people leadership. If we do not focus on one goal, even with the best technology we may not succeed. Just my 2 cents.
-harendra
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
wrote: Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes
more
time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu
-- Sergiu
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net

I disagree that this is a disaster waiting to happen. Other language
communities have multiple competing ideas and implementations, and it
doesn't harm them too much. Haskell is still rapidly evolving and serves
many different distinct sub-communities and needs, and it would be very
surprising indeed if a single solution worked for all of them.
Forcing (or even requesting) people to abandon their priorities and goals
for "the greater good" will not work. Infrastructure that allows for code
reuse and cooperation across distinct priorities will allow these
sub-communities to grow and prosper. It's best if each community solves
it's needs as well as it can, and allow the good ideas to spread via
cross-pollination.
Any new initiative that seeks to unify disparate groups without
acknowledging their differing priorities and goals will fail. I don't know
what will work, but friction is rarely resolved by increasing pressure.
Matt Parsons
On Mon, Feb 5, 2018 at 12:34 PM, Brandon Allbery
We have two groups of "leaders", with partially opposing goals. This is a disaster looking for an excuse to happen.
On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar
wrote: On 6 February 2018 at 00:33, Sergiu Ivanov
wrote: Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100):
Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries.
Interestingly the problem of too many choices and no standard one that can be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write their own? I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in the short/long run.
A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort in this direction, has been recently announced:
Unfortunately, in my opinion, SLURP is taking things exactly in the opposite direction. I was talking about the problem of choice above and SLURP is giving even more choices and therefore encouraging more fragmentation. We should have just one good choice to stop wasting time and energy finding the best choice among millions available. Everyone should focus on making that one choice better rather spending energy in creating their own alternatives. This is where the Haskell ecosystem philosophy differs, it provides many choices in all aspects, it may be good in some cases but not always. SLURP is a technology solution which exactly fits in the same DNA. Technology can help us achieve the tasks that we set out to do but technology cannot motivate and influence us in what we choose to do and therefore ti cannot make the community focus on one goal - that requires real people leadership. If we do not focus on one goal, even with the best technology we may not succeed. Just my 2 cents.
-harendra
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
wrote: Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100):
The irony is that theoretically you can find a Haskell package or implementation of whatever you can imagine but quite often it takes
more
time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu
-- Sergiu
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

If there are genuine priorities and if we can afford the luxury to have
those priorities, yes I agree with you. But Haskell is a tiny community
with little resources. Our chances of survival and winning are much
brighter if all of us put our efforts in one direction rather than dividing
them up into tinier parts, in other words set your priorities right for
success. There is no "greater good", everything boils down to our own good,
if the ship sinks we all sink together with it. Most successful projects
are successful because of the focused efforts driven from top. Diversity
and competition is always good as long as it is driven by genuine needs. I
sincerely wish that SLURP is successful and mitigates all problems plaguing
the ecosystem, but I doubt that the wish will come true.
-harendra
On 6 February 2018 at 01:57, Matt
I disagree that this is a disaster waiting to happen. Other language communities have multiple competing ideas and implementations, and it doesn't harm them too much. Haskell is still rapidly evolving and serves many different distinct sub-communities and needs, and it would be very surprising indeed if a single solution worked for all of them.
Forcing (or even requesting) people to abandon their priorities and goals for "the greater good" will not work. Infrastructure that allows for code reuse and cooperation across distinct priorities will allow these sub-communities to grow and prosper. It's best if each community solves it's needs as well as it can, and allow the good ideas to spread via cross-pollination.
Any new initiative that seeks to unify disparate groups without acknowledging their differing priorities and goals will fail. I don't know what will work, but friction is rarely resolved by increasing pressure.
Matt Parsons
On Mon, Feb 5, 2018 at 12:34 PM, Brandon Allbery
wrote: We have two groups of "leaders", with partially opposing goals. This is a disaster looking for an excuse to happen.
On Mon, Feb 5, 2018 at 2:29 PM, Harendra Kumar
wrote: On 6 February 2018 at 00:33, Sergiu Ivanov
wrote: Yes, Hayoo seems to be giving better results, I found more variants having the behavior I want, it seems this variant is quite popular but still not in any standard libraries.
Interestingly the problem of too many choices and no standard one
be discovered applies to search engines as well. In this case there are only two choices but still it is of the same nature. I knew about hayoo but forgot to use it in this case. How much time should one spend on finding a trivial function before giving up and making the choice to write
I wish there was a standard, quick, good quality way of discovering what to use. It seems the Haskell ecosystem DNA encourages more and more fragmentation rather than consolidation. I think the community/leaders should acknowledge this problem and work on making things better in
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 18:30 (+0100): that can their own? the
short/long run.
A Single Liberal Unified Registry of Haskell Packages (SLUPR), an effort in this direction, has been recently announced:
Unfortunately, in my opinion, SLURP is taking things exactly in the opposite direction. I was talking about the problem of choice above and SLURP is giving even more choices and therefore encouraging more fragmentation. We should have just one good choice to stop wasting time and energy finding the best choice among millions available. Everyone should focus on making that one choice better rather spending energy in creating their own alternatives. This is where the Haskell ecosystem philosophy differs, it provides many choices in all aspects, it may be good in some cases but not always. SLURP is a technology solution which exactly fits in the same DNA. Technology can help us achieve the tasks that we set out to do but technology cannot motivate and influence us in what we choose to do and therefore ti cannot make the community focus on one goal - that requires real people leadership. If we do not focus on one goal, even with the best technology we may not succeed. Just my 2 cents.
-harendra
-harendra
On 5 February 2018 at 22:02, Sergiu Ivanov
wrote: Hello Harendra,
Thus quoth Harendra Kumar on Mon Feb 05 2018 at 16:43 (+0100): > > The irony is that theoretically you can find a Haskell package or > implementation of whatever you can imagine but quite often it takes more > time to discover it than writing your own.
Sometimes Hayoo! helps me out in such situations:
http://hayoo.fh-wedel.de/?query=groupBy
utility-ht shows up.
-- Sergiu
-- Sergiu
_______________________________________________ Haskell-Cafe mailing list To (un)subscribe, modify options or view archives go to: http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Only members subscribed via the mailman list are allowed to post.
-- brandon s allbery kf8nh sine nomine associates allbery.b@gmail.com ballbery@sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
participants (4)
-
Brandon Allbery
-
Harendra Kumar
-
Matt
-
Sergiu Ivanov