Re: [ghc-steering-committee] #380 GHC2021: Current status

Hello, Joachim, would the voting system get a lot more complicated if we added a bit of ranked voting (e.g., instead of no,maybe,yes) we went (-2: strong reject, -1: reject, 0: don't care, 1: accept, 2: strong accept)? At least in my votes, I have a few extensions that I certainly feel strong about, and for some of them I just picked something but I don't really care either way, and I don't think that's captured in the votes. Let me know if that's OK, and I'll find some time to update my votes. Also, I've been busy with work, so when there are a bunch of e-mails like today (which is fun!), it is hard to keep up with what people have said about the many threads going on. If we adopt the haddock like commenting system, would it be possible to scrape the e-mails and auto generate a summary of what people have said for various things? This could also help with a final document where we not only pick the extensions, but also have some provenance about what people thought about the various extensions. -Iavor On Thu, Dec 3, 2020 at 8:58 AM Simon Peyton Jones via ghc-steering-committee wrote:

I voted against GADTs and am not yet inspired to change that vote: GADTs cause trouble for type inference. For example:

Yes, but there is no prospect (that I know of) of a substantial improvement in this – and what we have does not seem to cause problems in practice. And they are jolly useful and popular!

Simon

*From:* ghc-steering-committee *On Behalf Of *Richard Eisenberg *Sent:* 03 December 2020 16:32 *To:* Alejandro Serrano Mena *Cc:* ghc-steering-committee@haskell.org; Joachim Breitner < mail@joachim-breitner.de> *Subject:* Re: [ghc-steering-committee] #380 GHC2021: Current status

On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena wrote:

- GADTs:

- Stable and well documented,

- Adding indices to types is one of the main reasons one would like to have MultiParamTypeClasses and TypeFamilies on,

- I find the GADT syntax much nicer (but this is an extremely personal choice.)

I voted against GADTs and am not yet inspired to change that vote: GADTs cause trouble for type inference. For example:

data T a where

MkT :: Int -> T a

foo (MkT x) = x

GHC can infer that foo :: T a -> Int.

But if I change this to

data T a where

MkT :: Int -> T Int

foo (MkT x) = x

(where T is now a GADT) GHC can no longer infer my type. It complains about untouchable variables. This is a case of a "bad failure mode", where a simple error in input can lead to a very complicated error message in output. I thus think that users should knowledgeably opt into GADTs. Maybe if we had a much gentler error message in place here, I could be convinced otherwise. But, for now:

Vote against GADTs!

Richard

PS: A counterpoint is RankNTypes, which I voted for. It would be hard to accidentally write a higher-rank type, and I find the error messages that arise are much clearer. Yes, it's an advanced feature, but one that is appropriately (in my opinion) gated in the code. _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee