[ghc-steering-committee] Scoping of types

[Joachim Breitner]

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
  http://www.joachim-breitner.de/