- ghc-devs - Haskell.org

rolling span and groupBy for lists
by Harendra Kumar 05 Feb '18

05 Feb '18

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 predicate. 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 predicate. 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 place for these, if any. Can they be included in Data.List in base? Thanks, Harendra

4 6

Re: [Haskell-cafe] rolling span and groupBy for lists
by Harendra Kumar 05 Feb '18

05 Feb '18

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 <sivanov(a)colimite.fr> 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 >

1 0

Re: rolling span and groupBy for lists
by Harendra Kumar 05 Feb '18

05 Feb '18

I was mainly asking if it makes sense to include these functions in base/Data.List. Since the base package is maintained and ships along with ghc, and the issues are also raised at ghc trac I thought this is the right list. I am copying to libraries(a)haskell.org as well. -harendra On 5 February 2018 at 09:53, David Feuer <david(a)well-typed.com> wrote: > This is the wrong list. You probably meant to email haskell-cafe or > perhaps libraries(a)haskell.org. > > > > David Feuer > Well-Typed, LLP > > -------- Original message -------- > From: Harendra Kumar <harendra.kumar(a)gmail.com> > Date: 2/4/18 10:50 PM (GMT-05:00) > To: ghc-devs(a)haskell.org > Subject: rolling span and groupBy for lists > > 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 predicate. > 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 predicate. > 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 place > for these, if any. Can they be included in Data.List in base? > > Thanks, > Harendra >

1 0

Nested CPR patch review
by Matthew Pickering 29 Jan '18

29 Jan '18

Hi all, I recently resurrected akio's nested cpr branch and put it on phabricator for review. https://phabricator.haskell.org/D4244 Sebastian has kindly been going over it and ironed out a few kinks in the last few days. He says now that he believes the patch is correct. Is there anything else which needs to be done before merging this patch? Simon, would you perhaps be able to give the patch a look over? Cheers, Matt

3 5

https://downloads.haskell.org/~ghc/master/
by Joachim Breitner 28 Jan '18

28 Jan '18

Hi, just curious: What is the status of https://downloads.haskell.org/~ghc/master/ where I would expect the documentation of GHC HEAD? It seems to be last updated in October, and also be missing the GHC API docs. Cheers, Joachim -- Joachim Breitner mail(a)joachim-breitner.de http://www.joachim-breitner.de/

2 1

GHC builds are broken
by David Feuer 27 Jan '18

27 Jan '18

The Linux build has been failing with a segfault. It looks to me as though this started with 0e022e56b130ab9d277965b794e70d8d3fb29533: Turn EvTerm (almost) into CoreExpr.

3 3

Re: [ANNOUNCE] GHC 8.4.1-alpha2 available
by Ryan Scott 25 Jan '18

25 Jan '18

Forgive me if I'm stating the obvious here, but the status of libraries like primitive, unordered-containers, and haskell-src-exts don't really have anything to do with GHC, since they're independent libraries that aren't shipped with GHC in any way. If you're impatient to use the Haskell library ecosystem with GHC 8.4.1, I highly encourage you to use a solution like head.hackage [1], as many library authors are not as much of early adopters as we are :) Ryan S. ----- [1] https://github.com/hvr/head.hackage

1 0

[ANNOUNCE] GHC 8.4.1-alpha1 available
by Ben Gamari 22 Jan '18

22 Jan '18

The GHC development team is pleased to announce the first alpha release of the 8.4.1 release. The usual release artifacts are available from https://downloads.haskell.org/~ghc/8.4.1-alpha1 Note that this release drops compatibility with GCC 4.6 and earlier. While we generally try to place as few constraints on system toolchain as possible, this release depends upon the __atomic__ builtins provided by GCC 4.7 and later (see #14244). === Notes on release scheduling === The 8.4.1 release marks the first release where GHC will be adhering to its new, higher-cadence release schedule [1]. Under this new scheme, major releases will be made in 6-month intervals with interstitial minor releases as necessary. In order to minimize the likelihood of schedule slippage and to ensure adequate testing, each major release will be preceeded by a number of regular alpha releases. We will begin issuing these releases roughly three months before the final date of the major release and will issue roughly one every two weeks during this period. This high release cadence will allow us to quickly get fixes in to users hands and allow better feedback on the status of the release. GHC 8.4 is slated to be released in mid-February but, due to technical constraints, we are starting the alpha-release cycle a bit later than planned under the above schedule. For this reason, it would be greatly appreciated if users could put this alpha through its paces to make up for lost time. As always, do let us know if you encounter any trouble in the course of testing. Thanks for your help! Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/blog/2017-release-schedule

4 7

Extracting representation from GHC
by Németh Boldizsár 19 Jan '18

19 Jan '18

Dear GHC Developers, I would like to ask your opinion on my ideas to make it easier to use development tools with GHC. In the past when working on a Haskell refactoring tool I relied on using the GHC API for parsing and type checking Haskell sources. I extracted the representation and performed analysis and transformation on it as it was needed. However using the refactorer would be easier if it could work with build tools. To do this, my idea is to instruct GHC with a compilation flag to give out its internal representation of the source code. Most build tools let the user to configure the GHC flags so the refactoring tool would be usable in any build infrastructure. I'm thinking of using the pre-existing plugin architecture and adding two new fields to the Plugin datastructure. One would be called with the parsed representation (HsParsedModule) when parsing succeeds, another with the result of the type checking (TcGblEnv) when type checking is finished. What do you think about this solution? Boldizsár (ps: My first idea was using frontend plugins, but I could not access the representation from there and --frontend flag changed GHC compilation mode.)

5 5

RE: Why is EvTerm limited?
by Simon Peyton Jones 19 Jan '18

19 Jan '18

| What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? This has come up before. I think that'd be a solid win. In fact, eliminate all the existing evidence constructors with "smart constructors" that produce an EvExpr. That'd mean moving stuff from the desugarer into these smart constructors, but that's ok. I /think/ I didn't do that initially only because there were very few forms and it mean that there was no CoreExpr stuff in the type checker. But as we add more forms that decision looks and less good. You'd need to add zonkCoreExpr in place of zonkEvTerm. evVarsOfTerm is called quite a bit; you might want to cache the result in the EvExpr constructor. Make a ticket and execute? Simon | -----Original Message----- | From: Glasgow-haskell-users [mailto:glasgow-haskell-users- | bounces(a)haskell.org] On Behalf Of Joachim Breitner | Sent: 19 January 2018 14:01 | To: Glasgow-Haskell-Users users <glasgow-haskell-users(a)haskell.org> | Subject: Why is EvTerm limited? | | Hi, | | I had some funky idea where a type checker plugin would have to | synthesize code for a custom-solved instances on the fly. But it seems | that does not work because EvTerm is less expressive than Core | (especially, no lambdas): | https://na01.safelinks.protection.outlook.com/?url=https:%2F%2Fdownloa | ds.haskell.org%2F~ghc%2F8.2.2%2Fdocs%2Fhtml%2Flibraries%2Fghc- | 8.2.2%2FTcEvidence.html%23t:EvTerm&data=02%7C01%7Csimonpj%40microsoft. | com%7C513ff7ae83914913225008d55f452dec%7C72f988bf86f141af91ab2d7cd011d | b47%7C1%7C0%7C636519673089385423&sdata=kFkUugVn02Nfu4QXJ6dkVwtx8KWFrTM | fWcVEiwf6KyI%3D&reserved=0 | | What would break if we had | | | EvExpr CoreExpr | | as an additional constructor there? | | Cheers, | Joachim | | -- | Joachim “nomeata” Breitner | mail(a)joachim-breitner.de | | https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=02%7C01%7Csimonpj%40microsoft.com%7C513ff7ae839149 | 13225008d55f452dec%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636519 | 673089385423&sdata=Vh4BvbeEVUBIntKcf3XEseOzwUTx2RHPuANTY328dpM%3D&rese | rved=0

1 0