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:

On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud <arnaud.spiwack@tweag.io> wrote:
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).

I think we should express an opinion about the intended direction. Are we advising that ExtendedForallScope is a dead end, because we want TypeAbstraction?

Cheers
Simon

 

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.

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) = …`.

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.

Best,
Arnaud

_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee