[ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com
Simon Peyton Jones
simonpj at microsoft.com
Tue Dec 15 12:25:07 UTC 2020
Joachim and Iavor write pros for existential quantification that I don't understand. I tried "suggest improvement", but those suggestions are invisible unless you relally drill down.
| -----Original Message-----
| From: ghc-steering-committee <ghc-steering-committee-
| bounces at haskell.org> On Behalf Of Joachim Breitner
| Sent: 14 December 2020 22:23
| To: ghc-steering-committee at haskell.org
| Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /
| Dear Committe,
| three weeks in, we have all votes. So now things are looking more
| As always, the table
| has the current data.
| Would it be helpful to add columns to that table for each committee
| member? So that you can quickly see who voted what?
| The following in are safely in (= need more than one vote to change to
| get out):
| BangPatterns, BinaryLiterals, ConstrainedClassMethods,
| ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor,
| DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase,
| EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts,
| FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving,
| HexFloatLiterals, ImportQualifiedPost, InstanceSigs, KindSignatures,
| MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds,
| PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType,
| TypeApplications, TypeSynonymInstances
| The following are barely in (exactly 8 votes in favor, and 3 against):
| ExistentialQuantification, NamedWildCards, StandaloneKindSignatures,
| The following are short one vote (7 in favor, 4 against):
| DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds,
| NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections,
| I am sure we can have plenty of discussion for each of these. Probably
| without end. As Simon says, mailing lists don't scale. So I think we
| have two choices:
| 1. Let the numbers decide, and accept whatever comes out. According to
| the process (which we should only follow if we find it helpful) we'd
| maybe update our votes, and maybe point out new facets, for one week,
| and then just take whatever has 8 votes.
| 2. Explore a more efficient discussion format.
| For the latter I mentioned kialo.com before, and maybe it is worth a
| try, so I set up a discussion there:
| So what do you see there?
| There is a discussion tree:
| The root is "what goes in GHC2021"
| The next layer are all extensions with 7 or 8 votes.
| (I assume we should focus on those initially, but feel free to add
| more or ask me to.) For example: TupleSections
| And then each of these has a column where we can collect Pros and
| For example:
| Pro: Opt-in Syntax
| Con: Possible clash with extra-comma syntax extensions.
| So you can treat it like a wiki, but with structure to organize the
| In fact, each pro and con is itself a node where you can add
| supporting and disagreeing comments. This means that if you _disagree_
| that TupleSections are actually Opt-in syntax, there is a dedicated
| place to raise that point, rather than putting "Not actually opt-in"
| in the Con column of TupleSections...
| A good way to navigate the discussion seems to be the radial icon in
| the top left; it opens a radial view of the whole discussion, and you
| can read arguments by hovering.
| The site doesn't offer voting, it is only about structuring the
| discussion, and it is designed for much larger and much more
| contentious debates (e.g. "Brexit"). So we'll see how well it works
| for us and if it's helpful.
| Joachim Breitner
| mail at joachim-breitner.de
| ghc-steering-committee mailing list
| ghc-steering-committee at haskell.org
More information about the ghc-steering-committee