<div dir="ltr"><div class="gmail_default" style="font-family:tahoma,sans-serif">
Of course, I think we all understand that all these extensions are opt-in, and the behaviour of GHC would not change, for existing modules, would not change if this proposal was accepted. <br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">
<div>> I think we should express an opinion about the intended direction. 
Are we advising that ExtendedForallScope is a dead end, because we want 
TypeAbstraction?</div>

</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">One way to think of it is this: if Haskell had type-abstraction from Day 1, would we ever have introduced ExtendedForAllScope?  I'm sure we would not.  Even at the time we introduced it, I remember we were concerned that it was a very strange (non-nested) scoping construct.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">We bind term variables in patterns on the LHS; it makes sense to do the same for type variables.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">So yes, in that sense the story is that we recommend TypeAbstraction for introducing a scoped type variable.  Thus, instead of</div><div class="gmail_default" style="font-family:tahoma,sans-serif">```</div><div class="gmail_default" style="font-family:tahoma,sans-serif">id :: forall a. a -> a</div><div class="gmail_default" style="font-family:tahoma,sans-serif">id x = (x :: a)</div><div class="gmail_default" style="font-family:tahoma,sans-serif">```</div><div class="gmail_default" style="font-family:tahoma,sans-serif">we would have</div><div class="gmail_default" style="font-family:tahoma,sans-serif">```</div><div class="gmail_default" style="font-family:tahoma,sans-serif">id :: forall a. a -> a</div><div class="gmail_default" style="font-family:tahoma,sans-serif">id @b x = (x::b)   -- I have used a different name only for illustrative purposes; could also be 'a'.<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">```</div><div class="gmail_default" style="font-family:tahoma,sans-serif">We have to repeat that type-variable pattern in each equation for the function. But we also have to repeat the term variables, and we just take that for granted.</div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">But as a "recommendation", it's a pretty weak one.  You are still free to use either ExtendedForAllScope or TypeAbstraction or both at once in a particular module (subject to point 5 of 5.2).   So it's a bit like let-vs-where, or H98 data decls vs GADTs.  Do we even need a firm "recommendation"?<br></div><div class="gmail_default" style="font-family:tahoma,sans-serif"><br></div><div class="gmail_default" style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 1 Apr 2022 at 08:27, Simon Marlow <<a href="mailto:marlowsd@gmail.com">marlowsd@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>In the spirit of not accepting proposals that lead to language forks, it would be great to get some clarification on the concerns that Arnaud raises here:<br></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"><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></blockquote><div><br></div><div>I think we should express an opinion about the intended direction. Are we advising that ExtendedForallScope is a dead end, because we want TypeAbstraction?</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><div> </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><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></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>