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

On Thu, 17 Dec 2020 at 08:15, Spiwack, Arnaud wrote:

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.

I strongly agree with Arnuad here. Cheers Simon

On Tue, Dec 15, 2020 at 10:22 PM Richard Eisenberg 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee