<div dir="ltr"><div>Dear Committee<br></div><div><br></div><div>We're in danger of actually *removing* an extension from the default set of extensions that is enabled in GHC, which is not what I understood GHC2021 was all about. And it's not because anyone (at least as far as I know) actually thinks that ForeignFunctionInterface is a bad idea and should be deprecated or replaced. What other reasons could there be for turning off an extension that has been on by default for so many years?</div><div><br></div><div>ForeignFunctionInterface is part of Haskell2010. Are we saying we disagree with the decision to make it a part of the language standard? I hope not!</div><div><br></div><div>Please let's think very hard before doing this!</div><div><br></div><div>Cheers</div><div>Simon<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 14 Dec 2020 at 22:22, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Dear Committe,<br>
<br>
three weeks in, we have all votes. So now things are looking more concrete.<br>
<br>
As always, the table<br>
<a href="https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/blob/ghc2021/proposals/0000-ghc2021.rst#data</a><br>
has the current data.<br>
<br>
Would it be helpful to add columns to that table for each committee<br>
member? So that you can quickly see who voted what?<br>
<br>
The following in are safely in (= need more than one vote to change to get out):<br>
<br>
BangPatterns, BinaryLiterals, ConstrainedClassMethods, ConstraintKinds,<br>
DeriveDataTypeable, DeriveFoldable, DeriveFunctor, DeriveGeneric,<br>
DeriveLift, DeriveTraversable, EmptyCase, EmptyDataDecls,<br>
EmptyDataDeriving, ExplicitForAll, FlexibleContexts, FlexibleInstances,<br>
GADTSyntax, GeneralisedNewtypeDeriving, HexFloatLiterals,<br>
ImportQualifiedPost, InstanceSigs, KindSignatures,<br>
MultiParamTypeClasses, NamedFieldPuns, NumericUnderscores, PolyKinds,<br>
PostfixOperators, RankNTypes, StandaloneDeriving, StarIsType,<br>
TypeApplications, TypeSynonymInstances<br>
<br>
The following are barely in (exactly 8 votes in favor, and 3 against):<br>
<br>
ExistentialQuantification, NamedWildCards, StandaloneKindSignatures,<br>
TypeOperators<br>
<br>
The following are short one vote (7 in favor, 4 against):<br>
<br>
DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds,<br>
NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections,<br>
TypeFamilies<br>
<br>
<br>
I am sure we can have plenty of discussion for each of these. Probably<br>
without end. As Simon says, mailing lists don't scale. So I think we<br>
have two choices:<br>
<br>
1. Let the numbers decide, and accept whatever comes out. According to<br>
the process (which we should only follow if we find it helpful) we’d<br>
maybe update our votes, and maybe point out new facets, for one week,<br>
and then just take whatever has 8 votes.<br>
<br>
or<br>
<br>
2. Explore a more efficient discussion format.<br>
<br>
For the latter I mentioned <a href="http://kialo.com" rel="noreferrer" target="_blank">kialo.com</a> before, and maybe it is worth a<br>
try, so I set up a discussion there:<br>
<a href="https://www.kialo.com/which-haskell-extensions-should-go-into-ghc2021-43548?path=43548.0" rel="noreferrer" target="_blank">https://www.kialo.com/which-haskell-extensions-should-go-into-ghc2021-43548?path=43548.0</a><br>
<br>
So what do you see there?<br>
<br>
There is a discussion tree:<br>
<br>
The root is “what goes in GHC2021”<br>
<br>
The next layer are all extensions with 7 or 8 votes.<br>
(I assume we should focus on those initially, but feel free to add<br>
more or ask me to.)<br>
For example: TupleSections<br>
<br>
And then each of these has a column where we can collect Pros and cons.<br>
For example:<br>
Pro: Opt-in Syntax<br>
Con: Possible clash with extra-comma syntax extensions.<br>
<br>
So you can treat it like a wiki, but with structure to organize the<br>
discussion.<br>
<br>
In fact, each pro and con is itself a node where you can add supporting<br>
and disagreeing comments. This means that if you _disagree_ that<br>
TupleSections are actually Opt-in syntax, there is a dedicated place to<br>
raise that point, rather than putting “Not actually opt-in” in the Con <br>
column of TupleSections…<br>
<br>
A good way to navigate the discussion seems to be the radial icon in<br>
the top left; it opens a radial view of the whole discussion, and you<br>
can read arguments by hovering.<br>
<br>
<br>
The site doesn't offer voting, it is only about structuring the<br>
discussion, and it is designed for much larger and much more<br>
contentious debates (e.g. “Brexit”). So we’ll see how well it works for<br>
us and if it’s helpful.<br>
<br>
Cheers,<br>
Joachim<br>
<br>
<br>
-- <br>
Joachim Breitner<br>
<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
<a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
<br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>