- 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.)
GADTs must be one of Haskell’s most successful innovations ever. It’s a big feature, but it’s extremely well established now, and widely used. Users like GADTs – it’s #7 in the “popularity” column.
Vote for GADTs 😊.
My reservations around adding GADTs are really only reservations around MonoLocalBinds.However, as has been pointed out, TypeFamilies also implies MonoLocalBinds (this probably shouldn’t have been news to me), so I suppose I’d ought to go with both or neither!
Given that choice, I think I’d rather add GADTs to my “yes” list than add TypeFamilies to my “no” list. Joachim, sorry to mess up your statistics again :)
I agree with Simon that we must have GADTs!
On Dec 3, 2020, at 4:40 AM, Alejandro Serrano Mena <trupill@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 whereMkT :: Int -> T afoo (MkT x) = xGHC can infer that foo :: T a -> Int.But if I change this todata T a whereMkT :: Int -> T Intfoo (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!
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!
On Dec 3, 2020, at 11:58 AM, Simon Peyton Jones <simonpj@microsoft.com> wrote:Yes, but there is no prospect (that I know of) of a substantial improvement in [type inference for GADTs] – and what we have does not seem to cause problems in practice. And they are jolly useful and popular!The problem I described would arise when someone who does not know about GADTs and type inference accidentally writes a GADT. But this cannot happen easily today, precisely because of the need to write the extension.Useful, popular, and stable all help argue for an extension (and I agree here!), but I'm more concerned about error messages and the beginner experience, captured in our Criterion 2 of https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst#criteria.
On Thu, Dec 3, 2020 at 6:31 PM Richard Eisenberg <rae@richarde.dev> wrote:The problem I described would arise when someone who does not know about GADTs and type inference accidentally writes a GADT. But this cannot happen easily today, precisely because of the need to write the extension.Useful, popular, and stable all help argue for an extension (and I agree here!), but I'm more concerned about error messages and the beginner experience, captured in our Criterion 2 of https://github.com/ghc-proposals/ghc-proposals/blob/master/proposals/0372-ghc-extensions.rst#criteria.This is not a very believable objection in my opinion. GADTs are guarded by a different syntax which isn't used by someone who doesn't know about GADTs. So writing a GADT by accident is exceedingly unlikely. Besides, Ocaml has GADTs by default (with a similar syntax split as Haskell's). I don't believe I've ever heard anybody complain about GADTs since they've landed, certainly of anybody writing one by mistake.