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

[Simon Peyton Jones]

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 <ghc-steering-committee-bounces at haskell.org> On Behalf Of Richard Eisenberg
Sent: 03 December 2020 16:32
To: Alejandro Serrano Mena <trupill at gmail.com>
Cc: ghc-steering-committee at haskell.org; Joachim Breitner <mail at joachim-breitner.de>
Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status




On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill at gmail.com<mailto:trupill at gmail.com>> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/95058c0b/attachment-0001.html>