On Tue, 15 Dec 2020 at 13:00, Simon Peyton Jones via ghc-steering-committee <ghc-steering-committee@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@gmail.com>
Sent: 15 December 2020 12:48
To: Simon Peyton Jones <simonpj@microsoft.com>
Cc: Joachim Breitner <mail@joachim-breitner.de>; ghc-steering-committee@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@haskell.org> wrote:

Writing down the summary here
https://docs.google.com/document/d/1BMJtUQGk1HKOFgLnczybAwd1HgqbNpZA7elM4VnANa8/edit?usp=sharing

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@haskell.org> 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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e7
|  09a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
|  7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQI
|  joiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=3i5Pfxw2%2B
|  XKtfsbkhbwjreFArYCfvMDGyw%2F0ctxJfKs%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10
|  d0e709a1dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%
|  7C0%7C637435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiL
|  CJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=I8nLXqK
|  Mf32ctvlrPcPS%2BKBD%2FSw5vrV%2B0Fv%2BYvP%2Bbho%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1
|  dd4525973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
|  7435813779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV
|  2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=7N%2FDBw%2BRwVr
|  DcVqSS7BQroJAg8R3ccoLQ9Hua%2FgwbAE%3D&amp;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&amp;data=04%7C01%7Csimonpj%40microsoft.com%7C10d0e709a1dd452
|  5973708d8a07ecdad%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C6374358
|  13779684920%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMz
|  IiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&amp;sdata=byGDRSmjPqFiUAGe5fjF
|  vrhFIuQCjAldYzwMCrzrIac%3D&amp;reserved=0
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee