RE: Type family constraints
I’m afraid I don’t understand the question. 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 You mean, the first group does not work, but the latter does?? I’m not even sure what “work” means. I’m perplexed and need more context Simon From: ghc-devs On Behalf Of Alan & Kim Zimmerman Sent: 23 April 2018 11:57 To: ghc-devs Subject: Type family constraints 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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
RE: primitive library
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 Sent: 23 April 2018 14:20 To: Simon Peyton Jones Cc: David Feuer ; ghc-devs ; Haskell Libraries 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 mailto:simo...@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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Eight GHC projects for Google Summer of Code
Congratulations to all. I look forward to seeing these move forward. Alan On 23 April 2018 at 18:55, Matthew Pickering wrote: > 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 > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Eight GHC projects for Google Summer of Code
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Type family constraints
Thanks Richard Ryan Scott has also put together a solution[1], which is basically what you proposed. But in terms of trying to clean up the code by removing a straightforward constraint type, I think this solution adds more complexity than it removes. So I will leave it as it is. Alan [1] http://lpaste.net/365181 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: primitive library
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 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 > 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 > librar...@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Type family constraints
> On Apr 23, 2018, at 6:56 AM, Alan & Kim Zimmerman wrote: > > Is there any way to express that `pass` must be valid for each value of > `Pass` in the following instance head? > No, there isn't. And for good reason: whatever you're trying to do likely requires some runtime decision-making, and that's impossible with just type-level information. (Even without that motivation, there's this: any way of doing this would likely break type soundness. See #7259 and #14420.) My recommendation is to have > class ValidPass p > instance ValidPass Parsed > instance ValidPass Renamed > instance ValidPass Typechecked My guess is that you'll need to add a method to ValidPass, anyway. Richard___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Re: Plan for GHC 8.6.1
Perhaps Nested CPR will be ready :) ? https://phabricator.haskell.org/D4244 I am also working on the linear types branch. Arnaud is quite keen for it to be ready for 8.6 but we still have a bit to go. Cheers, Matt On Fri, Apr 20, 2018 at 1:26 AM, Ben Gamari wrote: > Hello fellow lazy purists, > > With GHC 8.4.2 out the door, it is time to begin looking forward to > 8.6.1. In keeping with our six-month release schedule, this release will > be targetted for early-September, with the stable branch being cut in > mid-to-late June. > > Remarkably, this is only 6 weeks away. If you have patches that you > would like to see in 8.6.1, please do put them up on Phabricator and the > 8.6.1 status page [1] in the coming weeks to ensure that there is > sufficient time for review. > > If you have a patch which you are concerned won't make the cut-off, do > say something. > > Cheers, > > - Ben > > > [1] https://ghc.haskell.org/trac/ghc/wiki/Status/GHC-8.6.1 > > ___ > ghc-devs mailing list > ghc-devs@haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
Type family constraints
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
primitive library
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 ___ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
