<div dir="ltr"><div dir="ltr"><div>Yes, we did. And that's largely on me: I got lost in the debates.</div><div><br></div><div>Reading back, my feeling is that: there is broad agreement on the proposed changes, as long as we move the “let” bits to another proposal (they have barely been discussed anyway). There are discussions on the precise meaning and wording of the principles (as far as I'm aware, I am the only one that questions the existence of one of the principle (the <span><span><span><span><span>Contiguous Scoping Principle), there is a discussion on whether the </span></span></span></span></span>Local Lexical Scoping Principle and the Explicit Binding Principle are really to be distinct.</div><div><br></div><div>Considering all this, I think that the best move is to accept the proposal, as soon as the “let”-related changes have been removed from the proposal. If the wording or details of the principles turn out to need tuning, we can always amend in a future proposal.</div><div><br></div><div>Richard, do you agree?</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jul 4, 2022 at 6:41 PM Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div style="font-family:tahoma,sans-serif">Arnaud</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">We've had this "Scoped type variables" proposal on our table for too long.  Is there anything stopping us from making a decision?</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><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>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><br></span></span></span></span></span></div><div><span><span><span><span><span>---</span></span></span></span></span></div><div><span><span><span><span><span><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>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><br></span></span></span></span></span></div><div><span><span><span><span><span>Best,</span></span></span></span></span></div><div><span><span><span><span><span>Arnaud<br></span></span></span></span></span></div><div><br></div></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
</blockquote></div></div>