[ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept

[Simon Peyton Jones]

Arnaud

We've had this "Scoped type variables" proposal on our table for too long.
Is there anything stopping us from making a decision?

Simon

On Tue, 29 Mar 2022 at 16:02, Spiwack, Arnaud <arnaud.spiwack at tweag.io>
wrote:

> Dear all,
>
> Let me bring to your attention the Modern Scoped Type Variables proposal,
> by our own Richard https://github.com/ghc-proposals/ghc-proposals/pull/448
> .
>
> 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.
>
> What this proposal tries to achieve is to make a consistent text about all
> the recent changes to binding type variables.
>
> The proposal adds new principles to the `principles.rst` files which
> inform the changes proposed, of these, I have the following comments:
> - The 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
> - The 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.
> - The 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.
>
> ---
>
> 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.
>
> These are mostly uncontroversial and the specification makes sense to me.
> I'm in favour of accepting all that.
>
> 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).
>
> 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 at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220704/df342908/attachment.html>