[ghc-steering-committee] GHC2021 extensions should be sufficient for early intermediate Haskellers

[Spiwack, Arnaud]

I don't agree with this sentiment at all, to be honest. In my opinion, the
ultimate fate of every extension is to be rolled into the standard or to be
relegated to the bins of history. The idea of having various levels of
languages based on how advanced they are perceived to be sounds
extraordinary to me (also quite a bit patronising).

Generally speaking, you opt in to a feature by using it. GHC2021 should not
have features that we, as a community, don't recommend using (the
bins-of-history ones); but, surely, TypeFamilies is not one of these. It is
not to say that GHC2021 should have TypeFamilies, but that them being
perceived as advanced is not, in my opinion, a relevant criterion. We
should be asking, instead, whether it is ready.

On Tue, Dec 15, 2020 at 10:22 PM Richard Eisenberg <rae at richarde.dev> wrote:

> Hi all,
>
> In thinking about how I feel about TypeFamilies (and why I lean against
> inclusion), I realized I had a new criterion:
>
> * GHC2021 extensions should be sufficient for early-intermediate Haskellers
>
> Today, users have to enable a number of extensions just to get basic work
> done (I'm looking at you, FlexibleContexts). So they learn just to take
> whatever suggestion is presented to them in an error message and apply it.
>
> But if extensions were considered more exotic, then users might not be so
> willing to add an extension. They would have to consider whether they
> really want to opt into more challenging error messages and a wider
> horizon. TypeFamilies is an extension that significantly widens the
> horizon, but also invites new scary error messages. I think it should be
> opt in. But this gatekeeping works only if users will be thoughtful about
> enabling the extension; thus my new criterion.
>
> What do we think about this?
>
> (I thought of putting this on Kialo, but it didn't seem to fit the setup
> there. Maybe I've erred in not just blasting ahead.)
>
> Richard
> _______________________________________________
> 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/20201217/5c8b0055/attachment.html>