Re: GHC HEAD vs Hackage, panic-free edition

Hello Bryan, On 2013-10-11 at 20:27:08 +0200, Bryan O'Sullivan wrote: [...]

For packages that are listed in blue, the versions that are breaking are the latest available. I've CCed the authors of said packages on this email. Folks, please fix your stuff!

btw, is there somewhere some wiki-page/gist/whatever where howto/cookbook-like information is being collected on how to make packages compatible with the new environment (possibly maximizing the compatibility version range)?

From eir at cis.upenn.edu Tue Oct 1 03:58:34 2013 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 30 Sep 2013 23:58:34 -0400 Subject: TypeLits Message-ID: X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000

Hi Iavor, It was very nice to see you last week -- it's too bad we have to wait another year for another ICFP! :) A question I got asked between sessions at ICFP led me to look at singletons again, and it seems that singletons has gone out of sync with TypeLits. When I looked closely at TypeLits, I saw a number of changes there, and I wonder if we can think a bit about the design before 7.8 rolls out. Forgive me if some of these suggestions are not new -- I just haven't looked closely at TypeLits for some time. Specifically: - I see that you define singleton instances for Bool. This makes sense, if we are to avoid orphan instances of the various singletons classes. But, it would seem helpful to define singleton support for more than just Bool here, if we are going down this road. For example, singletons for [], Maybe, Either, and the tuples are quite useful. - You don't export the constructors for Sing (k :: Bool). I think these need to be publicly visible. - I believe that Edward's reflection package will be incorporated into base. (Edward?) If so, it's possible that incoherentForgetSing can be cleaned up somewhat. - Why use LocalProxy? What's wrong with plain old Proxy? - I see Show and Read instances defined for singletons. Though these are useful, they prevent clients from defining their own instances, and I can imagine a user (possibly me) wanting a singleton to have a distinct Show instance from its base type. Perhaps these should be moved to a different module which can selectively be imported? - The definition for (:~:) is redundant with the new Data.Type.Equality. - The eqSing... functions are now redundant with the EqualityT class in Data.Type.Equality. Instead, TypeLits should probably define instances for EqualityT. - TypeLits defines KindIs, which is redundant with Data.Proxy's KProxy. It might be that KindIs is easier to use than KProxy, but base probably shouldn't have both types floating around. - I'm confused about IsZero. How is it different (in practical usage situations) from eqSingNat? Also, I'd like to note that IsZero uses a unary representation, which might be problematic. - The definitions for Nat1 don't need to be in base. Perhaps we want them there -- I think it will get a lot of use -- but maybe we should just think about it for a moment before going forward. I should admit that the redundancies are new -- after some discussion in the spring, I finally implemented the new bits that are now redundant with TypeLits only a month or two ago. --- Now having posed these questions, here are my proposed answers: - To avoid orphans, TypeLits should define singleton instances for all the types above, with all constructors exported. - Remove redundancy with other parts of base. I personally prefer KProxy over KindIs, because I find the KindIs name confusing. - Remove Show instances for singletons from base. If someone thinks these will have wide use, they can be defined in a library. - Keep Nat1 right where it is. Thoughts, anyone? Thanks, Richard

From simonpj at microsoft.com Tue Oct 1 09:32:17 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 1 Oct 2013 09:32:17 +0000 Subject: Symbolic type variables (was Re: [Proposal] Renaming (:=:) to (==)) In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1485F60E8@DB3EX14MBXC306.europe.corp.microsoft.com> X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000

| > I'm hoping we don't get more deeply invested in the syntactic change | in GHC | > 7.6 that removed the possibility of symbolic type variables ("~>", | "*", "+", | > etc). I had a new job and wasn't paying attention when SPJ polled the | > community. From my perspective, the loss has much greater scope than | the | > gain for type level naturals. I'd like to keep the door open to the | > possibility of bringing back the old notation with the help of a | language | > pragma. It would take a few of us to draft a proposal addressing | details. | | I also miss these on a regular basis. I seem to remember that during | the proposal, there was a mention of reversing the situation, i.e. | having a prefix for type variable operators instead. Did anything ever | come of that? I'm very open to concrete suggestions about this. I want Haskell to allow you to express the thoughts in your head, as directly as possible. We could add a LANGUAGE pragma. Or, more radically, we could support both at once, like this: data (&&) a b where ...blah blah... f :: Int && Int -> Bool f = ... data T (&&) x = MkT (x && x) -- Shadows (&&) The idea is that (&&) can be declared as a top-level type constructor, but then *shadowed* by an explicit local binding in the 'data T' declaration. This is somewhat analogous to the situation with values: f = True g f = f::Char where we define f globally and then shadow it. The apparent difference is that the top-level (&&) is a type constructor, whereas the local (&&) is a type variable; and in the value world we *never* shadow data constructors. But the counter-argument might be that type variables (unlike term variables) really do behave like type constructors: they are rigid and don't match anything else. So I think the door stands open here, if anyone wants to drive the debate and push it through to a consensus. Simon

From simonpj at microsoft.com Tue Oct 1 09:50:46 2013 From: simonpj at microsoft.com (Simon Peyton-Jones) Date: Tue, 1 Oct 2013 09:50:46 +0000 Subject: TypeLits In-Reply-To: References: Message-ID: <59543203684B2244980D7E4057D5FBC1485F6213@DB3EX14MBXC306.europe.corp.microsoft.com> X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000

Great post. It would be very good to clear this up asap, ie before 7.8, which itself is imminent. I'm agnostic about all of this ... from my pov just go ahead! Simon | -----Original Message----- | From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of | Richard Eisenberg | Sent: 01 October 2013 04:59 | To: Iavor Diatchki | Cc: libraries Libraries | Subject: TypeLits | | Hi Iavor, | | It was very nice to see you last week -- it's too bad we have to wait | another year for another ICFP! :) | | A question I got asked between sessions at ICFP led me to look at | singletons again, and it seems that singletons has gone out of sync with | TypeLits. When I looked closely at TypeLits, I saw a number of changes | there, and I wonder if we can think a bit about the design before 7.8 | rolls out. Forgive me if some of these suggestions are not new -- I just | haven't looked closely at TypeLits for some time. | | Specifically: | | - I see that you define singleton instances for Bool. This makes sense, | if we are to avoid orphan instances of the various singletons classes. | But, it would seem helpful to define singleton support for more than | just Bool here, if we are going down this road. For example, singletons | for [], Maybe, Either, and the tuples are quite useful. | | - You don't export the constructors for Sing (k :: Bool). I think these | need to be publicly visible. | | - I believe that Edward's reflection package will be incorporated into | base. (Edward?) If so, it's possible that incoherentForgetSing can be | cleaned up somewhat. | | - Why use LocalProxy? What's wrong with plain old Proxy? | | - I see Show and Read instances defined for singletons. Though these are | useful, they prevent clients from defining their own instances, and I | can imagine a user (possibly me) wanting a singleton to have a distinct | Show instance from its base type. Perhaps these should be moved to a | different module which can selectively be imported? | | - The definition for (:~:) is redundant with the new Data.Type.Equality. | | - The eqSing... functions are now redundant with the EqualityT class in | Data.Type.Equality. Instead, TypeLits should probably define instances | for EqualityT. | | - TypeLits defines KindIs, which is redundant with Data.Proxy's KProxy. | It might be that KindIs is easier to use than KProxy, but base probably | shouldn't have both types floating around. | | - I'm confused about IsZero. How is it different (in practical usage | situations) from eqSingNat? Also, I'd like to note that IsZero uses a | unary representation, which might be problematic. | | - The definitions for Nat1 don't need to be in base. Perhaps we want | them there -- I think it will get a lot of use -- but maybe we should | just think about it for a moment before going forward. | | | I should admit that the redundancies are new -- after some discussion in | the spring, I finally implemented the new bits that are now redundant | with TypeLits only a month or two ago. | | --- | | Now having posed these questions, here are my proposed answers: | | - To avoid orphans, TypeLits should define singleton instances for all | the types above, with all constructors exported. | - Remove redundancy with other parts of base. I personally prefer KProxy | over KindIs, because I find the KindIs name confusing. | - Remove Show instances for singletons from base. If someone thinks | these will have wide use, they can be defined in a library. | - Keep Nat1 right where it is. | | Thoughts, anyone? | | Thanks, | Richard | _______________________________________________ | Libraries mailing list | Libraries at haskell.org | http://www.haskell.org/mailman/listinfo/libraries

From ekmett at gmail.com Tue Oct 1 17:49:24 2013 From: ekmett at gmail.com (Edward Kmett) Date: Tue, 1 Oct 2013 13:49:24 -0400 Subject: TypeLits In-Reply-To: References: Message-ID: X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000 X-List-Received-Date: Sat, 12 Oct 2013 07:43:21 -0000

I've been talking to Austin about GHC.Reflection. He'd expressed some interest in taking a whack at it. If he doesn't get to it before this weekend, then I will. Re Proxy, we now have Proxy# as well. -Edward On Mon, Sep 30, 2013 at 11:58 PM, Richard Eisenberg <eir at cis.upenn.edu>wrote:

Hi Iavor,

It was very nice to see you last week -- it's too bad we have to wait another year for another ICFP! :)

A question I got asked between sessions at ICFP led me to look at singletons again, and it seems that singletons has gone out of sync with TypeLits. When I looked closely at TypeLits, I saw a number of changes there, and I wonder if we can think a bit about the design before 7.8 rolls out. Forgive me if some of these suggestions are not new -- I just haven't looked closely at TypeLits for some time.

Specifically:

- I see that you define singleton instances for Bool. This makes sense, if we are to avoid orphan instances of the various singletons classes. But, it would seem helpful to define singleton support for more than just Bool here, if we are going down this road. For example, singletons for [], Maybe, Either, and the tuples are quite useful.

- You don't export the constructors for Sing (k :: Bool). I think these need to be publicly visible.

- I believe that Edward's reflection package will be incorporated into base. (Edward?) If so, it's possible that incoherentForgetSing can be cleaned up somewhat.

- Why use LocalProxy? What's wrong with plain old Proxy?

- I see Show and Read instances defined for singletons. Though these are useful, they prevent clients from defining their own instances, and I can imagine a user (possibly me) wanting a singleton to have a distinct Show instance from its base type. Perhaps these should be moved to a different module which can selectively be imported?

- The definition for (:~:) is redundant with the new Data.Type.Equality.

- The eqSing... functions are now redundant with the EqualityT class in Data.Type.Equality. Instead, TypeLits should probably define instances for EqualityT.

- TypeLits defines KindIs, which is redundant with Data.Proxy's KProxy. It might be that KindIs is easier to use than KProxy, but base probably shouldn't have both types floating around.

- I'm confused about IsZero. How is it different (in practical usage situations) from eqSingNat? Also, I'd like to note that IsZero uses a unary representation, which might be problematic.

- The definitions for Nat1 don't need to be in base. Perhaps we want them there -- I think it will get a lot of use -- but maybe we should just think about it for a moment before going forward.

I should admit that the redundancies are new -- after some discussion in the spring, I finally implemented the new bits that are now redundant with TypeLits only a month or two ago.

---

Now having posed these questions, here are my proposed answers:

- To avoid orphans, TypeLits should define singleton instances for all the types above, with all constructors exported. - Remove redundancy with other parts of base. I personally prefer KProxy over KindIs, because I find the KindIs name confusing. - Remove Show instances for singletons from base. If someone thinks these will have wide use, they can be defined in a library. - Keep Nat1 right where it is.

Thoughts, anyone?

Thanks, Richard _______________________________________________ Libraries mailing list Libraries at haskell.org http://www.haskell.org/mailman/listinfo/libraries