[ghc-steering-committee] Modern Scoped Type Variables #448: recommendation (mostly) accept
Spiwack, Arnaud
arnaud.spiwack at tweag.io
Mon Apr 4 07:50:46 UTC 2022
On Mon, Apr 4, 2022 at 9:33 AM Simon Peyton Jones <
simon.peytonjones at gmail.com> wrote:
> So it's a bit like let-vs-where, or H98 data decls vs GADTs. Do we even
> need a firm "recommendation"?
>
I think that there are two aspects to consider here, which make me think
that: yes, we probably want a stronger form of recommendation (even in the
extensions-are-switches-to-tune-GHC's-behaviour worldview)
1. Let and where, as well as the two syntaxes for data types are perfectly
compatible with one another. You can use both at the same time, and people
do. While ExtendedForAllScope and TypeAbstractions are at odds with each
other. Granted, the proposal gives a semantics to having both of them on.
But still, they are not good friends. So you probably actually don't want
to mix them. This point is highlighted by the fact that the proposal makes
ExtendedForAllScope an extension with the explicit purpose of being able to
deactivate this behaviour. Nobody ever asked to deactivate lets or the
Haskell 98 syntax for data types.
2. As the proposal stands it's easier to use ExtendedForAllScope than to
use TypeAbstraction. Because you will usually use it in conjunction with
ScopedTypeVariables, and ScopedTypeVariables implies the former but not the
latter. Therefore, ExtendedForAllScope requires turning a single extension
while TypeAbstractions requires two. Therefore, from the point of view of
the programmer, ExtendedForAllScope will feel like more of a default
choice. If we think that TypeAbstractions ought to be the default choice,
then we need to make it at least as easy as ExtendedForAllScope.
/Arnaud
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20220404/f63c208f/attachment.html>
More information about the ghc-steering-committee
mailing list