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

Wed Apr 26 13:32:30 UTC 2023

I agree with Simon. These all seem entirely reasonable ways of using the compiler to me.

Chris  

> On 26 Apr 2023, at 13:23, Simon Peyton Jones <simon.peytonjones at gmail.com> wrote:
> 
>> 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 <mailto: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 <mailto:ghc-steering-committee at haskell.org>
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
> _______________________________________________
> 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/63cd6352/attachment.html>