Re: [ghc-steering-committee] Scoping of types

Yes, indeed. Time is remarkably squeezed for me right now (which is why I'm working on a Sunday morning). Don't expect any action here before September. But I plan to synthesize this little bundle of proposals into something coherent soon. I don't expect any real changes over what's currently proposed -- just a more coherent & unified presentation, accompanied by typing rules. Richard

On Aug 14, 2021, at 11:40 AM, Simon Peyton Jones wrote:

I spoke to Richard about this. He is planning to respond to your call

| What do you think, how should we proceed? Does anyone feel a calling to | guide this process to a conclusion?

Maybe his shepherding of #425 (invisible binders in type declarations) is a good fit with that enterprise.

Thank you Richard!

Simon

| -----Original Message----- | From: ghc-steering-committee On | Behalf Of Joachim Breitner | Sent: 09 August 2021 10:55 | To: ghc-steering-committee@haskell.org | Subject: Re: [ghc-steering-committee] Scoping of types | | Hi, | | I wasn't technically asking you to shepherd it, merely to assign a shephard | and write the necessary mails and other red tape that I wasn't keen on doing | on the phone while traveling. But now I have a proper keyboard again, so I | can do this. Or I can try. | | There are three proposals in the air that are somewhat related, and might be | worth being shepherded together. We have done that before, and it makes | great sense. In fact, I would consider it within the powers of a shepherd to | take two related proposal and work them into one. | | We have these proposals that related to "type variables and patterns": | (summaries are mine and might be wrong) | | #291: Simplify scoping for type applications in patterns | | This makes the "a" in a (Just @a _) pattern to always bind a new | type variable, it is never an occurrence (as it would be under | the accepted "#126 Type Varialbes in TPatterns" | | #238: Introduce -XTypeAbstractions, limiting -XScopedTypeVariables | | This refines/fixes "#155 Binding type variables in λ exprs", | splits up ScopedTypeVariables, introduces a @(..) short-hand | (the dots are syntax, not metasyntax). | | #420: no-implicit-binds: Adjust defaulting of -XPatternSignatureBinds | | This modifies "#285 -XNoImplicitForAll, - | XNoPatternSignatureBinds", which itself partly breaks out | existing behavior into two new extensions (ImplicitForAll, | PatternSignatureBinds) | | Fun fact: #285 includes wording like "or, if #238 is accepted:" | | | So, if I see it correctly, we have _three_ accepted proposals related to | type variables (#126, #155, #285), which are all unimplemented. On top of | that, we have three open proposals modifying these. This is all very | confusing and doesn't feel quite effective to me. It's not unusual that | proposals are accepted but don't get implemented for a while, but it can be | a sign that they are not quite right yet. | | So I am almost of a mind to un-accept #126, #155, #285, and, together with, | #291, #238, #420 mark then at "needs unifiying revision", and asking the | authors and all interested parties to come up with one (1) unifying proposal | that covers it all. | | Well, maybe this is a bit too harsh, but in principle it seems more | productive to juggle this set of unimplemented proposals, proposal modifying | proposals and conditional proposals. | | Or maybe all it needs is a single shepherd who is motivated to clear this | jungle for us. | | What do you think, how should we proceed? Does anyone feel a calling to | guide this process to a conclusion? | | | Cheers, | Joachim | | -- | Joachim Breitner | mail@joachim-breitner.de | | https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.joachim | - | breitner.de%2F&data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077 | 015d08d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63764099718817 | 7261%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1 | haWwiLCJXVCI6Mn0%3D%7C1000&sdata=nUxjVT1dUp8eizt7faWgnuF%2BWWPHj6e2Rug3K | d5usGU%3D&reserved=0 | | | _______________________________________________ | ghc-steering-committee mailing list | ghc-steering-committee@haskell.org | https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.haske | ll.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-steering- | committee&data=04%7C01%7Csimonpj%40microsoft.com%7Cc73b2d6cfc814077015d0 | 8d95b1bc947%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637640997188177261% | 7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwi | LCJXVCI6Mn0%3D%7C1000&sdata=BkvvfLPKEqhO24Q%2FLVJXnW2i%2F5YiesjTMcA6FXC2 | zNI%3D&reserved=0