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

[Simon Peyton Jones]

 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.

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

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.

We bind term variables in patterns on the LHS; it makes sense to do the
same for type variables.

So yes, in that sense the story is that we recommend TypeAbstraction for
introducing a scoped type variable.  Thus, instead of
```
id :: forall a. a -> a
id x = (x :: a)
```
we would have
```
id :: forall a. a -> a
id @b x = (x::b)   -- I have used a different name only for illustrative
purposes; could also be 'a'.
```
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.

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"?

Simon

On Fri, 1 Apr 2022 at 08:27, Simon Marlow <marlowsd at gmail.com> wrote:

> 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 at 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> 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/20220404/872aeec4/attachment.html>