<div dir="ltr"><div>Dear all,</div><div><br></div><div>Let me bring to your attention the Modern Scoped Type Variables proposal, by our own Richard <a href="https://github.com/ghc-proposals/ghc-proposals/pull/448" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/448</a> .</div><div><br></div><div>The proposal is a touch intimidating, because the text is large. But most of it comes from other, already accepted, proposals that this proposal is tidying up and tying together.</div><div><br></div><div>What this proposal tries to achieve is to make a consistent text about all the recent changes to binding type variables.</div><div><br></div><div>The proposal adds new principles to the `principles.rst` files which inform the changes proposed, of these, I have the following comments:</div><div>- The <span><span>Visibility Orthogonality Principle doesn't seem to have a very clear definition. It may be a sign that it's not something that is so important</span></span></div><div><span><span>- The <span><span></span><span>Explicit Binding Principle says that we need to be able to enforce that all type variables have a binding site. I think it's a bit strong: I would like Haskell to let me write a binding site for every type variable, but not necessarily to error out when that doesn't happen. That being said, I'm happy with warnings to help me along the way, but I don't think that this Explicit Binding Principle should be phrased in a way that requires adding extensions to control this behaviour.</span></span></span></span></div><div><span><span><span><span>- The <span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">Contiguous Scoping Principle, which states that a binder binds in one contiguous region sounds dubious to me. I don't see a particular reason for this to be.</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">---</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">In the proposed changes themselves: up to Section 5, the proposed changes are mostly existing accepted proposals, cleaned up with what was learnt since they were written, as well as to adhere to the new principles.<br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">These are mostly uncontroversial and the specification makes sense to me. I'm in favour of accepting all that.</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">With the caveat that this proposal introduces quite a few extensions. And at this point, I'm still not quite sure what Richard recommends is the set of extensions that I should use (and I'm slightly dismayed that I believe that it will be a set of cardinal more than 1). I think this reflects a vision of extensions as switches to customise the behaviour of GHC. This vision, as I've stated before, is very alien to me: I see extensions as staging areas for features to become an integral part of Haskell. So I don't know what to think of all these extensions. I'm definitely not against splitting -XScopedTypeVariables into smaller components, if it is done so that they are reassembled in a different way in an alternative extension that would now be the recommended default (or at least is to become the next recommended default).</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">Finally, there are Sections 6 to 8. These are entirely new. Though they are working towards the new principles (well, as far as I can tell, Section 6 doesn't contribute to the principles, but it is a stepping stone for both Sections 7 and 8). These sections are concerned with adding local let-bindings of type variables, in particular inside types and patterns.</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">By the way, Section 7 proposes two syntaxes for let binders in patterns, and I  *strongly* prefer the second syntax, which reads something like `f (let b = Bool) (True :: Bool) = …`.</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">Anyway, these are new, I feel that they are a bit out of place in a proposal that is about tidying up the existing designs. That being said, they are here, and they seem like fairly uncontroversial to me, (except, probably the syntax `(let b = _)` to bind a variable to a type to be filled by the compiler). I'm fine with accepting these, though they may require a bit more scrutiny than the rest.</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass"><br></span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">Best,</span></span></span></span></span></div><div><span><span><span><span><span class="gmail-blob-code-inner gmail-blob-code-marker gmail-js-code-nav-pass">Arnaud<br></span></span></span></span></span></div><div><br></div></div>