In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.
I went down the list and in every case I thought "yes, language extensions
allow a user to do this, if they want". I struggled to answer your
questions. Eg
- X1 is this a use-case GHC should support. Well it already supports
it. I suppose we could debate which are active goals and which are
accidental, but before burning the midnight oil on that debate I'd love to
know where this is going.
- X2 is this use case best served by extensions. When you say "best
served" you imply that, in each case, there is a well-defined alternative
or alternatives that could be better. But I don't know what are the
alternatives that we should be comparing with.
- X3 Does GHC20xx help? What do you mean by "GHC20xx". I think you
mean "The occasional release of a new flag, GHC2025, say, that implies a
bunch of others. That seems a rather different debate, but in general I
think the idea is a good one, if not done too frequently
I feel as if I'm not being very helpful, which probably means I'm missing
the point somehow!
Simon
On Wed, 19 Apr 2023 at 13:21, Arnaud Spiwack
Dear all,
In Round 1', we have gathered no less than 13 use-cases (see below) found in the community for Haskellers to motivate the need for extensions. Some of these use-cases are specific to a pretty definite list of extensions, some are not. Some extensions fall squarely in one use-case, some don't. Use-cases are not a classification of extensions, they're a classification of justifications for extensions to exist. Surely we've missed some, but it's alright to not be fully exhaustive.
In this next round, I want us to give our opinion, on each of these use-cases, on whether we believe that this use-case is best served by extension. My goal, in this round, is not necessarily to build consensus for a policy, but to discover where there is consensus, and where there is controversy, so that we can discuss the relevant use-cases in more detail.
In this round, I'm asking you, for each X∈{1,…,13}, to answer the following questions:
X.1: do you believe that this a use-case that GHC should support? (yes/no) X.2: regardless of your answer in X.1, if GHC supports this use-case, do you believe that this use-case is best served by extensions. (yes/no) X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no) X.2.N: if you've answered “no” to X.2: what mechanism would you rather see supporting this use-case (free form)
I'll be on holiday next week, and will tally the results on the first week on May.
The 13 use-cases are
1. Gain early access to experimental or unstable features (e.g. because they're working on a research prototype, or because the feature is valuable enough to them to forgo some stability) 2. Restrict the use of more complex features (e.g. for easier onboarding of new developers or as educators to teach a well-delimited subset of the language) 3. Restrict the use of novel features since the last established standard/report. 4. Restrict the use to features that they don't like (e.g. controversial features like RecordWildcard or ImplicitParameters) 5. Name/refer to a particular feature when talking/writing/searching about it. 6. Restrict the use of features which require support from outside the Haskell ecosystem that can't be taken for granted (I think this concerns only UnicodeSyntax) 7. As library authors, to signal which features the library actually uses, hence which version of GHC the library is compatible with. 8. Retain access to deprecated features to smooth out migration over the deprecation period. 9. Retain access to deprecated features indefinitely. 10. Change the default behaviour of (part of) the language (e.g. StrictData, I think some of the dependent Haskell work falls in this category, but I can't pinpoint an example) 11. Extend the language in a way that is not backward compatible (e.g. OverloadedList, probably some dependent Haskell things too) 12. Enable features whose mere presence has a performance impact (e.g. Template Haskell, and that's probably it) 13. CPP (this one is very unique isn't it?) _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee