[ghc-steering-committee] Why not?, rather than, why?

[Joachim Breitner]

Hello Committee and Community,

occasionally we have meta-discussions about GHC language extensions:
Should they be allowed to be fork-like, where some extensions are
unlikely to be used together and some stay opt-in forever? Or should
(ideally) every extension be on track to become on-by-default.

Of course there are a few “old” extensions that by their very nature
are not suitable to be on by default (SAFE, TRUSTWORTHY and CPP are the
obvious candidates). Let’s put them aside for this discussion. I’d
wager that if we’d introduce them these days, they wouldn’t be language
extensions in the first place, but maybe modifiers on the module.

I am mostly in the camp “every extension should be on track to become
default (or be discarded)”. Once a language feature has been proven
useful and reasonable stable, I see little value in requiring
programmers to jump through hoops to use them.

Is that the prevalent view here as well, or do we have a strong camp
saying that our current “pick-and-choose” approach to language features
is actually a good thing in its own (and not just a necessary
nuisance)?

If we assume the former, then maybe it would be worth to frame the
discussion around new language extensions, and the discussion about
which language extensions become default, around that vision.
Concretely:

 * A new language proposal should not just be good enough for “worth 
   building for those who explicitly turn it on”, but really ought
   convince as “this will make Haskell better for all” (and not just
   “a Haskell”).

 * Most new language features should probably not on by default 
   initially, as usual, and are initially experimental. But then the
   proposal, and if accepted the documentation of the extension, should
   as explicit as possible explain why it is not yet default: What
   needs to happen for _this_  extension to be considered ready – or
   judged negatively and put on a track towards removal.

   This could be something like “been available for n releases, been
   stable for m releases”. (I wonder what other kind of criteria to
   expect here?)

 * The process for defining GHC20xx would then become very different:
   We’d go through all experimental extensions, check if the criteria
   are satisfied, maybe apply some common sense if the criteria are 
   still good ones, and turn it on if so.

This may turn the process to be more structured and maybe more
predictable, and hopefully reduces the number of non-default extensions
developers have to make a decision about (probably good).
But it does raise the bar for new language features (is that good?).
And, if applied consequently, it suggests to deprecate and eventually
remove extensions that turn out to not be default-worthy after all
(that’s kinda harsh)?

As you can see I am a bit unsure about what the criteria are that we
could put in the docs. Are they really different for different
extensions? But the fact that its hard to come up right now with a
concrete reason why extension X is not yet the default does point to a
hole in our thinking and our process!

And it is the same question that we face when discussing GHC20xx. So I
guess what I am proposing here is: Have that discussion (when is it
ready?) already when accepting a proposal, and document it in clear
sight for our users, rather than have it over and over when debating
GHC20xx.

This is not a concrete (meta-)proposal, but hopefully tasty food for
thought.

Cheers,
Joachim
   



-- 
Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/