We, as a committee, struggle to figure out a policy around extensions. This policy would help inform decisions such as:
* whether proposal X needs to come with an extension, can modify a previous one, or needs no extension at all
* how to evolve the set of extensions that are part of GHC20XX / the default set of extensions
Beyond these real-world challenges that the committee has faced, we might also want to consider
*
how better to communicate the role extensions play in the Haskell
language (anecdotes suggest the current story is off-putting to
newcomers)
* whether some extensions ought to be retired
I'm OK with those as goals, although I have not found myself stuck on them. E.g. most proposals do come with an extension because they are, well, an extension. And user opinions frankly differ about the value and tempo of GHC20XX.
The proposed solution(s)
Richard comes up with a couple of categorisations, which are indeed helpful. But he stops short of any concrete proposals.
1. Declare that extensions are experimental language features,
being evaluated for inclusion in the language proper. Gating some new
syntax behind an extension theoretically allows us to experiment,
improve, etc., until we are happy, and then we merge the feature into
the language, with no extension needed.
2. Declare that
extensions are configuration flags, meant to exist in perpetuity. In
this way, extensions are a more powerful form of warning flag: not only
can they dictate which programs are accepted, but sometimes they can be
used to change the semantics of an accepted program.
3. Organize the set of extensions around an idea of language levels, where we classify different extensions according to the expected level of expertise of users working in the extended language.
These aren't either/or choices. It's clear that
- some really are configuration flags (Safe, RebindableSyntax; maybe punning)
- some are definitely local, thin ice (UndecidableSuperclasses) -- the more we can turn these into local modifiers the better
- some are really part of the language we'd like to see (PolyKinds, MultiParamTypeClasses)
- some are experimental in the "Haskell as a laboratory" sense (Linear)
I think that classifying them might be helpful; choosing one of these paths over the others seems infeasible to me.
What next?
I suppose the next step is for some motivated person to write a draft policy paper, so we can say "This is the GHC steering committee's policy on extensions". Maybe it too can be a GHC proposal (rather like the design principles one). It can certainly include the categorisations Richard suggests.
Simon