[ghc-steering-committee] #380 GHC2021: Forth status update / kialo.com

Simon Marlow marlowsd at gmail.com
Tue Dec 15 20:27:43 UTC 2020


On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee
<ghc-steering-committee at haskell.org> wrote:

> My point is that NamedWildcards is a souped up version of
> PartialTypeSignatures
>
>
>
> f :: _ -> _
>
> g :: _a -> _a
>
>
>
> The former is a partial type signature. So is the latter!   The former is
> equivalent to f :: _a -> _b.
>
>
>
> Now, I’ve just discovered that
>
>    - Wildcards in types work **regardless** of flag.  Thus you can use
>    the above signature for f with no flag at all, and get a message like this:
>
> Foo.hs:5:6: error:
>
>     • Found type wildcard ‘_’ standing for ‘[a]’
>
>       Where: ‘a’ is a rigid type variable bound by
>
>                the inferred type of f :: [a] -> [a]
>
>                at Foo.hs:6:1-12
>
>       To use the inferred type, enable PartialTypeSignatures
>
> *So the only effect of PartialTypeSignatures is to turn that error into a
> warning.*  I had not appreciated that.
>
>
>
>    - As you say, NamedWildCards treats _a as a wildcard rather than a
>    variable.  Fine.
>
>
>
>    - Given the above, I still think it’s bizarre not to allow
>    PartialTypeSignatures.  All the complexity is there already; it’s only a
>    question of turning the error into a warning
>
>
It would be slightly strange to have a language feature that is enabled by
default but generates a warning every time you use it. I'd rather the
warning was disabled by default, but I agree that PartialTypeSignatures
should be on.

If I recall correctly, it was Richard who argued for NamedWildCards without
PartialTypeSignatures (or independently of it), somewhere deep in one of
these email threads :)

Cheers
Simon




>
>    -
>
>
>
> Simon
>
>
>
> *From:* Alejandro Serrano Mena <trupill at gmail.com>
> *Sent:* 15 December 2020 12:48
> *To:* Simon Peyton Jones <simonpj at microsoft.com>
> *Cc:* Joachim Breitner <mail at joachim-breitner.de>;
> ghc-steering-committee at haskell.org
> *Subject:* Re: [ghc-steering-committee] #380 GHC2021: Forth status update
> / kialo.com
>
>
>
>
>
> 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
>
> https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing
> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdocs.google.com%2Fdocument%2Fd%2F1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8%2Fedit%3Fusp%3Dsharing&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977856035%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nwXI1KIFwaFAf8WrdnXBF7MoNIhq2tTt0KIL0LVBCx8%3D&reserved=0>
>
> 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 <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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=EHZIchQsOdwrT6p5MuQUoWONZvUr8x35ACzUXFZk1HA%3D&reserved=0>
> |
> |  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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fub.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977866031%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=zmCppIBCXjqoVaZaXY1FWcKBcBBP8Pwni1jn7hkpBcU%3D&reserved=0>
> %2Fghc-proposals%2Fghc-
> |  proposals%2Fblob%2Fghc2021%2Fproposals%2F0000-
> |  ghc2021.rst%23data&data=04%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977876027%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=yWWXXXYhlgsc6DkoQ2pl%2Fg3W3FKR6wrlSN70mYDCoWE%3D&reserved=0>
> %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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0>
> 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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fkialo.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977886022%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=Qq0Ly%2Bi0BEtojVpMvmN9GqDs0ftVQp9%2B5DA0RQel7JI%3D&reserved=0>
> %2Fwhich-haskell-extensions-should-go-into-ghc2021-
> |  43548%3Fpath%3D43548.0&data=04%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gNhldU3ky0zZjdTamtkGkcXkYnij%2FnZfXZP%2FVA7pBh4%3D&reserved=0>
> %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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fbreitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977896016%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=gDY7g2ZbZUXmBOcZ965QbDXx%2FyqV0QTzLy28JY6PnTI%3D&reserved=0>
> %2F&data=04%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977906015%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=um%2Ba0XdBybuyBixCbfruJUGQRyHy%2BBaXDGbgFWIAu2k%3D&reserved=0>
> %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
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fhaskell.org%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iiZXGZCSRr4RgU0zb3UtblBFxJYUeM%2B8JBZ6goNbQsY%3D&reserved=0>
> %2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering-
> |  committee&data=04%7C01%7Csimonpj%40microsoft.com
> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2F40microsoft.com%2F&data=04%7C01%7Csimonpj%40microsoft.com%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977916012%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=o9BSWTudDLBqHILOY4c52gYrO7col9hS5OcJ6JTDT1k%3D&reserved=0>
> %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
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> <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%7C2aecc7661e8b44021c5508d8a0f7b034%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637436332977926004%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=iS6WeND3u5ArOZHO2KRvfEe1gV9%2BySwH%2BaeJbZQtMhg%3D&reserved=0>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201215/f8602f9e/attachment-0001.html>


More information about the ghc-steering-committee mailing list