[ghc-steering-committee] Language Extension Policy – Round 2

[Simon Peyton Jones]

>
> 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 <arnaud.spiwack at tweag.io>
wrote:

> 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 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/20230426/7c07a65d/attachment-0001.html>