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

[Simon Marlow]

On Mon, 4 Apr 2022 at 18:17, Richard Eisenberg <lists at richarde.dev> wrote:

> Thanks for kicking off this conversation, Arnaud!
>
> To be clear in this thread: I'm fine delaying the discussion of section
> 6-8 until later.
>
> Arnaud brings up my new principles in his initial email. Do please
> consider these principles as part of the deliberations, as they will become
> principles that we, as a committee, will have adopted.
>
> About extensions: We, as a community and as a committee, have not come to
> terms with the two possible interpretations of extensions. I would like to
> say that, ideally, extensions are candidates for eventual inclusion.
> However, that is neither the current practice nor our trendline. Examples:
>  - any flags included in Haskell98 (including, for example,
> MonomorphismRestriction). These are definitely settings that one can choose
> per module. If they were candidates for inclusion, they wouldn't exist
> (because they're already included!).
>  - RebindableSyntax (though this is not one to mimic)
>  - MagicHash. My interpretation is that this extension is meant to allow
> users to explicitly opt into low-level code.
>  - Recently accepted #285
> <https://github.com/ghc-proposals/ghc-proposals/pull/285>, which
> introduces two new -XNo... extensions (both also included in #448).
> As a practical matter, then, extensions are means of customization. We
> might imagine a debate where we try to change this, and then come up with a
> way to get from where we are to that changed future.
>

I think we actually did come to some agreement on the interpretation of
extensions, it's in our review criteria under "does not create a language
fork": https://github.com/ghc-proposals/ghc-proposals#review-criteria . Yes
there are plenty of extensions that don't fit this criteria, but they tend
to be either special-purpose extensions for things like low-level
programming, building DSLs, or for backwards compatibility, rather than
extensions we would expect people to routinely enable.

Does that apply in this case? Well, perhaps the extensions are not
technically incompatible, but they're "at odds" as Arnaud puts it.

Another way to frame the original question might be: which of these
extensions do we expect to include in GHC2023 (or GHC2024 or whatever it
ends up being)? GHC2021 already has ScopedTypeVariables. We did decide (if
I recall correctly) that we might remove things from future GHCXXXX sets,
so are we going to remove ExtendedForAllScope and add TypeAbstractions from
some future GHCXXXX, or just add TypeAbstractions?

I'm not expressing a preference one way or the other, just that we should
decide where this is going.

Cheers
Simon

Very specifically answering Simon M's concern: I see ExtendedForAllScope as
> a dead end, yes. It's included as a way of supporting the gobs and gobs and
> gobs of code that use today's ScopedTypeVariables, but at t=∞, we should
> get rid of it. Note that an optional extra
> <https://github.com/goldfirere/ghc-proposals/blob/type-variables/proposals/0448-type-variable-scoping.rst#58alternatives> introduces
> a @(..) syntax that makes TypeAbstractions significantly less repetitive,
> and thus about as easy to use as ExtendedForAllScope (which, recall,
> requires an explicit forall where there might otherwise be none).
>
> Richard
>
> PS: I'm on holiday starting tomorrow and so may not respond for about two
> weeks. Back in action on the 15th, but expect a few days of digging out.
> _______________________________________________
> 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/426f1584/attachment.html>