April 2018 - ghc-devs

Re: [GHC] #9476: Implement late lambda-lifting
by Nicolas Frisby 25 Apr '18

25 Apr '18

I'm happy this is seeing some attention! I've habitually over promised on this and feel bad about that. My work-life-hobby programming balance has remained a mystery to me. Even so, I'll give what answers I can to any questions that come up. I remember ultimately getting stuck on trying to identify a broadly useful heuristic: there are lots of possible parameters to tune and I was seeing massive run time differences for nofib cases on different CPU architectures for equivalent LLF parameters. I never managed to get a good handle on the crucial independent variables (e.g. code cache sizes, RTS parameters, etc). I'm hoping the join point work revealed some easier wins. Best of luck and don't hesitate to ping me with questions. Hope I can help. On Wed, Apr 25, 2018, 10:33 GHC <ghc-devs(a)haskell.org> wrote: > #9476: Implement late lambda-lifting > -------------------------------------+------------------------------------- > Reporter: simonpj | Owner: nfrisby > Type: feature request | Status: new > Priority: normal | Milestone: > Component: Compiler | Version: 7.8.2 > Resolution: | Keywords: > Operating System: Unknown/Multiple | Architecture: > Type of failure: Runtime | Unknown/Multiple > performance bug | Test Case: > Blocked By: | Blocking: > Related Tickets: #8763 | Differential Rev(s): > Wiki Page: LateLamLift | > -------------------------------------+------------------------------------- > > Comment (by simonpj): > > OK, great. Do keep us posted. I think there are real wins to be had > here. Nicholas's detailed wiki page identifies many of the issues very > clearly. > > -- > Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9476#comment:12> > GHC <http://www.haskell.org/ghc/> > The Glasgow Haskell Compiler >

1 0

RE: [core libraries] Re: Name for unary unboxed one-tuple
by Simon Peyton Jones 25 Apr '18

25 Apr '18

OK great, thanks. Solo# is it. Adding ghc-devs: would someone like to make a patch? Simon From: Edward Kmett <ekmett(a)gmail.com> Sent: 25 April 2018 17:13 To: Andrew Martin <andrew.thaddeus(a)gmail.com> Cc: Simon Peyton Jones <simonpj(a)microsoft.com>; core-libraries-committee(a)haskell.org; Haskell Libraries <libraries(a)haskell.org> Subject: Re: [core libraries] Re: Name for unary unboxed one-tuple Argh. Not another color for the bikeshed. We were so close to a nice universal consensus given your +1 on the thread. =) Let's end this and just go with Simon's Solo# as it had already achieved a reasonably wide consensus on the thread and we can put this to bed. Simon: I'd replied a couple of weeks ago on the trac ticket to try to end this, but apparently didn't visibly weigh in in a fashion that obviously carried the full force of the committee. -Edward On Wed, Apr 25, 2018 at 8:40 AM, Andrew Martin <andrew.thaddeus(a)gmail.com<mailto:andrew.thaddeus@gmail.com>> wrote: My vote is for Single/Single#. Also, in case there is any confusion around this, I was not a member of the CLC when this issue was originally raised, but the committee has accepted me since then. On Wed, Apr 25, 2018 at 4:28 AM, Simon Peyton Jones via Libraries <libraries(a)haskell.org<mailto:libraries@haskell.org>> wrote: Dear Libraries Committee Some time ago Andrew Martin asked you<https://mail.haskell.org/pipermail/libraries/2018-January/028419.html> what the name of the unary unboxed one-tuple type and data constructor should be. The thread ran for a while, but you never came to a conclusion. Can we nail this one? You’ll see on Trac #14673<https://ghc.haskell.org/trac/ghc/ticket/14673#comment:19> that chessai wants me to decide 😊. But it should really be you. To me, there seems to be something of a consensus around Solo#. Simon PS: actually I think Andrew may have addressed libraries@ rather than core-libraries-committee@ by mistake. _______________________________________________ Libraries mailing list Libraries(a)haskell.org<mailto:Libraries@haskell.org> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.haskel…> -- -Andrew Thaddeus Martin -- You received this message because you are subscribed to the Google Groups "haskell-core-libraries" group. To unsubscribe from this group and stop receiving emails from it, send an email to haskell-core-libraries+unsubscribe(a)googlegroups.com<mailto:haskell-core-libraries+unsubscribe@googlegroups.com>. For more options, visit https://groups.google.com/d/optout<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.goo…>.

2 3

GHC HCAR submission
by Ben Gamari 25 Apr '18

25 Apr '18

tl;dr. Add your project to GHC's HCAR submission [1]. Hello everyone, I have uploaded a first draft of GHC's May 2018 HCAR submission to the Wiki [1]. While I believe I have covered most of the on-going projects, do check that your project appears and feel free to make any edits you feel appropriate. Cheers, - Ben [1] https://ghc.haskell.org/trac/ghc/wiki/Status/Apr18

2 1

In which format should GHC expose documentation via its .hi-files?
by Simon Jakobi 24 Apr '18

24 Apr '18

Hi! In preparation for the coding phase of the Hi Haddock proposal that I want to implement, I need a decision on the format in which we should expose haddocks in GHC's .hi interface files. Please visit https://github.com/haskell/haddock/issues/805, ask questions, make suggestions and help me find a timely decision! :) Cheers, Simon

1 0

Type family constraints
by Alan & Kim Zimmerman 23 Apr '18

23 Apr '18

Given data GhcPass (c :: Pass) deriving instance Eq (GhcPass c) deriving instance Typeable c => Data (GhcPass c) data Pass = Parsed | Renamed | Typechecked deriving (Data) Is there any way to express that `pass` must be valid for each value of `Pass` in the following instance head? instance (p ~ GhcPass pass, OutputableBndrId p) => Outputable (HsIPBinds p) where This comes from a problem where setting each type family instance separately does not get picked up during instance resolution (and can't be, according to earlier questions by me on this) i.e. type instance XIPBinds (GhcPass 'Parsed) = NoExt type instance XIPBinds (GhcPass 'Renamed) = NoExt type instance XIPBinds (GhcPass 'Typechecked) = TcEvBinds it works fine for type instance XIPBinds (GhcPass _) = NoExt Alan

3 3

RE: primitive library
by Simon Peyton Jones 23 Apr '18

23 Apr '18

This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. That would be great, thanks. It would also mean that more people would use the new stuff, sooner. Simon From: Andrew Martin <andrew.thaddeus(a)gmail.com> Sent: 23 April 2018 14:20 To: Simon Peyton Jones <simonpj(a)microsoft.com> Cc: David Feuer <david(a)well-typed.com>; ghc-devs <ghc-devs(a)haskell.org>; Haskell Libraries <libraries(a)haskell.org> Subject: Re: primitive library I'll get something together soon that explains my motivations. The short summary is that the types in primitive unpack better that their counterparts in vector (meaning, they unpack into one machine word instead of three). I started using these types in internal data structures in libraries I would write (since I didn't need slicing), and then just started noticing stuff I thought it would be nice to add. David noticed that a bunch of the typeclass instances were broken. I'd been working on a library quickcheck-classes that I use to test instances at my work place. The primitive library was missing a test suite, so I used it to test all the instances to ensure that the fixes David had written were correct. In the process, I found more broken instances and fixed them. The life lesson here is that property testing is important. PrimArray is an interesting story. Both winterland1989 and I had independently written libraries that did the same exact thing: implement a typed interface to ByteArray that keeps track of the element type. This makes PrimArray much safer to work with than ByteArray. Eventually, winterland's initial PR to bring this to primitive stalled. It implemented several other features (some of which may still eventually get added), but it's scope was large enough that no maintainer was able to feel comfortable approving it. More recently, I took at stab at doing the same thing, but I only added PrimArray, and after a lot of feedback from David, Carter, and Ryan, it got merged in. This got longer than I thought it would. I'll work on something that talks more about motivations and features soon. On Mon, Apr 23, 2018 at 5:48 AM, Simon Peyton Jones <simonpj(a)microsoft.com<mailto:simonpj@microsoft.com>> wrote: Andrew, David I’ve seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon -- -Andrew Thaddeus Martin

1 0

Eight GHC projects for Google Summer of Code
by Matthew Pickering 23 Apr '18

23 Apr '18

Hi all, I am glad to report that eight GHC related projects have been selected for this years GSoC. Chitrak Gupta - Help Hadrian - https://summerofcode.withgoogle.com/projects/#4778106259243008 Alanas Plascinskas - Depecating Exports - https://summerofcode.withgoogle.com/projects/#4906802404130816 Simon Jakobi - HI Haddock - https://summerofcode.withgoogle.com/projects/#4975710121230336 Abhiroop Sarkar - SIMD Improvements - https://summerofcode.withgoogle.com/projects/#5641742712307712 Ningning Xie - Dependently Typed Core Replacement in GHC - https://summerofcode.withgoogle.com/projects/#5851493949767680 Andreas Klebinger - Codegen of Conditional Constructs - https://summerofcode.withgoogle.com/projects/#5953351515111424 Shayan Najd - Native-Metaprogramming Reloaded - https://summerofcode.withgoogle.com/projects/#6085694691213312 Zubin Duggal - Making GHC Tooling friendly - https://summerofcode.withgoogle.com/projects/#6509299262554112 I am sure that some names will already be familiar but please look out for questions and patches from these eight students over the next few months. Looking forward to seeing everyone on the mailing list and in #ghc! Cheers, Matt

2 1

Re: primitive library
by David Feuer 23 Apr '18

23 Apr '18

I think the areas in the primitive library demonstrate a part of the array design space that seems to have gone relatively unexplored in Haskell: plain old vectors. Unlike the vector library, there is no stream fusion framework. Unlike the array library, there is no class-based reliance on fold/build fusion. The (flawed) addition of numerous class instances a couple versions ago made primitive arrays seem much more viable to end users as an alternative to their heavier counterparts. I have become interested in fixing the mistakes that were made, seeing just how much performance we can squeeze out (and what limitations we run into), and fleshing out the API. On Mon, Apr 23, 2018, 9:20 AM Andrew Martin <andrew.thaddeus(a)gmail.com> wrote: > I'll get something together soon that explains my motivations. The short > summary is that the types in primitive unpack better that their > counterparts in vector (meaning, they unpack into one machine word instead > of three). I started using these types in internal data structures in > libraries I would write (since I didn't need slicing), and then just > started noticing stuff I thought it would be nice to add. > > David noticed that a bunch of the typeclass instances were broken. I'd > been working on a library quickcheck-classes that I use to test instances > at my work place. The primitive library was missing a test suite, so I used > it to test all the instances to ensure that the fixes David had written > were correct. In the process, I found more broken instances and fixed them. > The life lesson here is that property testing is important. > > PrimArray is an interesting story. Both winterland1989 and I had > independently written libraries that did the same exact thing: implement a > typed interface to ByteArray that keeps track of the element type. This > makes PrimArray much safer to work with than ByteArray. Eventually, > winterland's initial PR to bring this to primitive stalled. It implemented > several other features (some of which may still eventually get added), but > it's scope was large enough that no maintainer was able to feel comfortable > approving it. More recently, I took at stab at doing the same thing, but I > only added PrimArray, and after a lot of feedback from David, Carter, and > Ryan, it got merged in. > > This got longer than I thought it would. I'll work on something that talks > more about motivations and features soon. > > On Mon, Apr 23, 2018 at 5:48 AM, Simon Peyton Jones <simonpj(a)microsoft.com > > wrote: > >> Andrew, David >> >> I’ve seen a lot of traffic about the *primitive* library, in which you >> two are playing a leading role. >> >> Clearly something interesting is going on, but I have not been paying >> enough attention to work out what. Maybe lots of unrelated things? Maybe >> a handful of closely related things? >> >> Would you consider putting out a summary (to libraries and ghc-devs) to >> give an overview of the main threads, and any driving motivations. Why has >> all this blown up now? >> >> Meanwhile, thank you for being so active. >> >> Simon >> > > > > -- > -Andrew Thaddeus Martin > _______________________________________________ > Libraries mailing list > Libraries(a)haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries >

1 0

primitive library
by Simon Peyton Jones 23 Apr '18

23 Apr '18

Andrew, David I've seen a lot of traffic about the primitive library, in which you two are playing a leading role. Clearly something interesting is going on, but I have not been paying enough attention to work out what. Maybe lots of unrelated things? Maybe a handful of closely related things? Would you consider putting out a summary (to libraries and ghc-devs) to give an overview of the main threads, and any driving motivations. Why has all this blown up now? Meanwhile, thank you for being so active. Simon

1 0

HsVectInstIn is dead code?
by Alan & Kim Zimmerman 22 Apr '18

22 Apr '18

If I grep through the GHC source, or do a github search[1] It seems that HsVectInst exists, and can be renamed, typechecked, zonked, desugared. But it does not get parse, and does not appear to be introduced in any other way. Am I missing something? Should it be deleted (as hinted at in one of the comments?) Alan [1] https://github.com/ghc/ghc/search?utf8=%E2%9C%93&q=HsVectInstIn&type=

3 2