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

Tom Harding tomjharding at live.co.uk
Thu Dec 3 10:41:04 UTC 2020 

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 :)

Cheers,
Tom

On 3 Dec 2020, at 10:03, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>> wrote:

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 😊.

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org<mailto:ghc-steering-committee-bounces at haskell.org>> On Behalf Of Alejandro Serrano Mena
Sent: 03 December 2020 09:41
To: Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>>
Cc: ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
Subject: Re: [ghc-steering-committee] #380 GHC2021: Current status

Joachim, I love your statistics :) And I think I’m less sad that you made it look: I think that NullaryTypeClasses is implied by MultiParamTypeClasses, and that MonadFailDesugaring is already (or is going to be) the default in GHC! :P

To get some more discussion, I would be very happy to hear reasons for and against:

- 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.)

- RankNTypes:
  - I originally voted “no”, because I find it to be part of “advanced Haskell”, and because using it may be complicated without ImpredicativeTypes on,
  - On the other hand, it’s also been in GHC for ages.

On 3 Dec 2020 at 10:31:18, Joachim Breitner <mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>> wrote:
Dear Committee,


we have 9 votes in. Dear Cale and Eric, can we have your votes please?

As always, the table
https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fghc-proposals%2Fghc-proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654681789%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=rzZgJlwbhSUTgZ2bRgSMRTZiArUtaKdzyCJAdpC2wWk%3D&reserved=0>
has the current data.

We had the most discussion so far about:

* The innnocence of PostfixOperators
* The effect of UnicodeSyntax on error messages
* Whether InstanceSigs is a good design
* Whether OverloadedString is harmless enough.

I see that three is less clear signal on odd extensions that are
obsolete, on by default, implied by others etc. That’s probably fine
and no need to worry; some of them will be resolved by virtue of being
implied by others. We can also sanity-check the final result, and
include all implied ones in the final design.

So where do we stand?

Applying the actual quota of ⅔ out of 11, i.e. 8 votes, these would go
in no matter how Cale and Eric vote:

  BangPatterns, BinaryLiterals, ConstraintKinds, DeriveDataTypeable,
  DeriveFoldable, DeriveFunctor, DeriveGeneric, DeriveLift,
  DeriveTraversable, EmptyCase, EmptyDataDecls, EmptyDataDeriving,
  ExplicitForAll, FlexibleContexts, FlexibleInstances, GADTSyntax,
  HexFloatLiterals, ImportQualifiedPost, KindSignatures,
  MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores,
  StandaloneDeriving, ViewPatterns

The following have 6 or 7 votes, i.e. they’d go in if we extrapolate
from the current votes:

  ConstrainedClassMethods, DerivingStrategies,
  ExistentialQuantification, GeneralisedNewtypeDeriving, InstanceSigs,
  NegativeLiterals, PostfixOperators, RankNTypes, RecordWildCards,
  ScopedTypeVariables, TupleSections, TypeApplications, TypeFamilies,
  TypeOperators, TypeSynonymInstances

  These extensions are short one vote:

  DataKinds, DerivingVia, GADTs, LambdaCase, PolyKinds



  So how sad would we all be? This is the sadness report for each
  committee member, showing the symmetric difference between their ballot
  and the (extrapolated) result.


  alejandro
  would miss:
  DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring,
  NamedWildCards, NoMonomorphismRestriction, NullaryTypeClasses,
  NumDecimals, OverloadedLists, OverloadedStrings, PolyKinds,
  StandaloneKindSignatures
  doesn’t want:
  RankNTypes

  arnaud
  would miss:
  Arrows, ExplicitNamespaces, ForeignFunctionInterface,
  FunctionalDependencies, GADTs, MonadFailDesugaring, MonoLocalBinds,
  PartialTypeSignatures, StarIsType, TypeFamilyDependencies
  doesn’t want:
  ExistentialQuantification, ImportQualifiedPost, InstanceSigs,
  NamedFieldPuns, RankNTypes, RecordWildCards, ScopedTypeVariables,
  TupleSections, TypeSynonymInstances

  iavor
  would miss:
  BlockArguments, MultiWayIf, NoMonomorphismRestriction,
  NullaryTypeClasses, OverloadedStrings, ParallelListComp, RecursiveDo
  doesn’t want:
  ConstrainedClassMethods, ConstraintKinds, DeriveFoldable,
  DeriveFunctor, DeriveTraversable, DerivingStrategies, EmptyCase,
  GADTSyntax, GeneralisedNewtypeDeriving, InstanceSigs, KindSignatures,
  NegativeLiterals, PostfixOperators, TupleSections, TypeApplications,
  TypeFamilies, TypeOperators

  joachim
  would miss:
  DataKinds, DerivingVia, ForeignFunctionInterface, GADTs, LambdaCase,
  MonoLocalBinds, NamedWildCards, NondecreasingIndentation,
  RoleAnnotations, StarIsType, UnicodeSyntax, UnliftedFFITypes,
  UnliftedNewtypes
  doesn’t want:
  ConstrainedClassMethods, ScopedTypeVariables, TypeSynonymInstances

  richard
  would miss:
  BlockArguments, DefaultSignatures, DerivingVia,
  DisambiguateRecordFields, ExplicitNamespaces, LexicalNegation,
  NamedWildCards, NumDecimals, ParallelListComp, PolyKinds,
  RoleAnnotations, StandaloneKindSignatures, TemplateHaskellQuotes,
  UnicodeSyntax, UnliftedNewtypes
  doesn’t want:
  NegativeLiterals, RecordWildCards, ScopedTypeVariables, TypeFamilies

  simonm
  would miss:
  DataKinds, DefaultSignatures, ForeignFunctionInterface, GADTs,
  LambdaCase, LiberalTypeSynonyms, MonoLocalBinds, MultiWayIf,
  NoMonomorphismRestriction, NondecreasingIndentation, NumDecimals,
  OverloadedStrings, PatternSynonyms, PolyKinds, UnicodeSyntax
  doesn’t want:
  DeriveLift, DerivingStrategies, NumericUnderscores, TypeApplications,
  TypeOperators, ViewPatterns

  spj
  would miss:
  MonoLocalBinds, NoMonomorphismRestriction, NullaryTypeClasses,
  OverloadedLists, OverloadedStrings, ParallelListComp, PolyKinds,
  RecursiveDo, RoleAnnotations, StandaloneKindSignatures, StarIsType
  doesn’t want:
  DerivingStrategies, GeneralisedNewtypeDeriving, NegativeLiterals,
  RecordWildCards, TupleSections, TypeFamilies

  tom
  would miss:
  BlockArguments, DataKinds, DefaultSignatures, DerivingVia,
  DisambiguateRecordFields, DuplicateRecordFields, ExplicitNamespaces,
  FunctionalDependencies, LambdaCase, LexicalNegation,
  LiberalTypeSynonyms, MagicHash, MultiWayIf, NamedWildCards,
  NullaryTypeClasses, NumDecimals, PackageImports, ParallelListComp,
  PolyKinds, QuasiQuotes, RoleAnnotations, StandaloneKindSignatures,
  TemplateHaskell, TemplateHaskellQuotes, TypeFamilyDependencies,
  UnboxedSums, UnboxedTuples, UnicodeSyntax, UnliftedNewtypes
  doesn’t want:
  none!

  vitaly
  would miss:
  DataKinds, DerivingVia, GADTs, LambdaCase, MonadFailDesugaring,
  StarIsType
  doesn’t want:
  ConstrainedClassMethods, ExistentialQuantification, PostfixOperators


  --
  Joachim Breitner
 mail at joachim-breitner.de<mailto:mail at joachim-breitner.de>
 http://www.joachim-breitner.de/<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim-breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=5ZVahXxGFqEyoTMqj5ZitQaTKIIsSxu1G64gFcUFvjU%3D&reserved=0>


_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haskell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cd1b5e56aaa764f6028e308d8976f8dc3%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637425852654691785%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=hdxLRYi8jFlwCdrXzDjvDw%2B098%2B9tRWvg6KJt7NT02I%3D&reserved=0>
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee at haskell.org<mailto:ghc-steering-committee at haskell.org>
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201203/d8e86046/attachment-0001.html>

More information about the ghc-steering-committee mailing list