[ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com
Alejandro Serrano Mena
trupill at gmail.com
Tue Dec 15 12:48:12 UTC 2020
On 15 Dec 2020 at 13:18:20, Simon Peyton Jones via ghc-steering-committee <
ghc-steering-committee at haskell.org> wrote:
> Writing down the summary here
> 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.
> | -----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 /
> | 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 at 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 at 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 at haskell.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the ghc-steering-committee