On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee < ghc-steering-committee@haskell.org> wrote:
Writing down the summary here
https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnA...
allows me to ask:
* It can't be sensible to propose NamedWildCards (8 votes) without ParitalTypeSignatures (2 votes), can it?
As far as I understand it, they have different purposes: - 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.
f :: _a -> _a f ‘x’ = True
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’. - 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. Personally, I think this is the right behaviour: do not accept partial signatures unless explicitly told so.
Simon
| -----Original Message----- | From: ghc-steering-committee
On Behalf Of Joachim Breitner | Sent: 14 December 2020 22:23 | To: ghc-steering-committee@haskell.org | Subject: [ghc-steering-committee] #380 GHC2021: Forth status update / | kialo.com | | Dear Committe, | | three weeks in, we have all votes. So now things are looking more | concrete. | | As always, the table | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgith | ub.com%2Fghc-proposals%2Fghc- | proposals%2Fblob%2Fghc2021%2Fproposals%2F0000- | ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7 | 09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0% | 7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI | joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=3i5Pfxw2%2B | XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&reserved=0 | 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, | TypeOperators | | The following are short one vote (7 in favor, 4 against): | | DerivingStrategies, ForeignFunctionInterface, GADTs, MonoLocalBinds, | NegativeLiterals, RecordWildCards, ScopedTypeVariables, TupleSections, | TypeFamilies | | | 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. | | or | | 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: | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww. | kialo.com%2Fwhich-haskell-extensions-should-go-into-ghc2021- | 43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com%7C10 | d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1% | 7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL | CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=I8nLXqK | Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&reserved=0 | | 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 | cons. | 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 | discussion. | | 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. | | Cheers, | Joachim | | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.j | oachim- | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1 | dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63 | 7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV | 2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=7N%2FDBw%2BRwVr | DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | 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%7C10d0e709a1dd452 | 5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358 | 13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz | IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=byGDRSmjPqFiUAGe5fjF | vrhFIuQCjAldYzwMCrzrIac%3D&reserved=0 _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee