[ghc-steering-committee] Scoping of types

[Simon Peyton Jones]

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 <ghc-steering-committee-bounces at haskell.org> On
|  Behalf Of Joachim Breitner
|  Sent: 09 August 2021 10:55
|  To: ghc-steering-committee at 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 at 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 at 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