<html><body>
<div dir="ltr">
<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee <<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</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">
<div>
Writing down the summary here<br><a href="https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing">https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing</a><br><br>allows me to ask:<br><br>* It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?<br></div></blockquote><div class="gmail_quote"><br></div><div class="gmail_quote">As far as I understand it, they have different purposes:</div><div class="gmail_quote"><br></div><div class="gmail_quote">- NamedWildCards instructs GHC to treat names starting with underscore as unknown variables when unifying. So for example, the following would not work, since _a would need to be Char and Bool at the same time.</div><div class="gmail_quote"><br></div><div class="gmail_quote">> f :: _a -> _a</div><div class="gmail_quote">> f ‘x’ = True</div><div class="gmail_quote"><br></div><div class="gmail_quote">If you do not enable NamedWildCards, names starting with an underscore are taken to be regular variables. So the type ‘_a -> _a’ is completely equivalent to ‘a -> a’.</div><div class="gmail_quote"><br></div><div class="gmail_quote">- PartialTypeSignatures is about *accepting* those signatures by the compiler. If you don’t have this on, a partial type signature gives you an error with the inferred type, but does not continue compiling your program.</div><div class="gmail_quote"><br></div><div class="gmail_quote">Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.</div><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><br>Simon<br><br>| -----Original Message-----<br>| From: ghc-steering-committee <ghc-steering-committee-<br>| <a href="mailto:bounces@haskell.org">bounces@haskell.org</a>> On Behalf Of Joachim Breitner<br>| Sent: 14 December 2020 22:23<br>| To: <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br>| Subject: [ghc-steering-committee] #380 GHC2021: Forth status update /<br>| <a href="http://kialo.com">kialo.com</a><br>| <br>| Dear Committe,<br>| <br>| three weeks in, we have all votes. So now things are looking more<br>| concrete.<br>| <br>| As always, the table<br>| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith</a><br>| <a href="http://ub.com">ub.com</a>%2Fghc-proposals%2Fghc-<br>| proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-<br>| ghc2021.rst%23data&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com">40microsoft.com</a>%7C10d0e7<br>| 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%<br>| 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI<br>| joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B<br>| XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0<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<br>| get out):<br>| <br>| BangPatterns, BinaryLiterals, ConstrainedClassMethods,<br>| ConstraintKinds, DeriveDataTypeable, DeriveFoldable, DeriveFunctor,<br>| DeriveGeneric, DeriveLift, DeriveTraversable, EmptyCase,<br>| EmptyDataDecls, EmptyDataDeriving, ExplicitForAll, FlexibleContexts,<br>| FlexibleInstances, GADTSyntax, GeneralisedNewtypeDeriving,<br>| HexFloatLiterals, 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">kialo.com</a> before, and maybe it is worth a<br>| try, so I set up a discussion there:<br>| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww</a>.<br>| <a href="http://kialo.com">kialo.com</a>%2Fwhich-haskell-extensions-should-go-into-ghc2021-<br>| 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com">40microsoft.com</a>%7C10<br>| d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%<br>| 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL<br>| CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK<br>| Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0<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.) For example: TupleSections<br>| <br>| And then each of these has a column where we can collect Pros and<br>| 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<br>| supporting and disagreeing comments. This means that if you _disagree_<br>| that TupleSections are actually Opt-in syntax, there is a dedicated<br>| place to raise that point, rather than putting "Not actually opt-in"<br>| in the Con 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<br>| for 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">mail@joachim-breitner.de</a><br>| <br>| <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j</a><br>| oachim-<br>| <a href="http://breitner.de">breitner.de</a>%2F&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com">40microsoft.com</a>%7C10d0e709a1<br>| dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63<br>| 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV<br>| 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr<br>| DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0<br>| <br>| <br>| _______________________________________________<br>| ghc-steering-committee mailing list<br>| <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br>| <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail</a><br>| .<a href="http://haskell.org">haskell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-<br>| committee&data=04%7C01%7Csimonpj%<a href="http://40microsoft.com">40microsoft.com</a>%7C10d0e709a1dd452<br>| 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358<br>| 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz<br>| IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF<br>| vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0<br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</blockquote>
</div>
</div>
</body></html>