<div dir="ltr">Dear all,<br><br>In Round 1', we have gathered no less than 13 use-cases (see below)<br>found in the community for Haskellers to motivate the need for<br>extensions. Some of these use-cases are specific to a pretty definite<br>list of extensions, some are not. Some extensions fall squarely in one<br>use-case, some don't. Use-cases are not a classification of<br>extensions, they're a classification of justifications for extensions<br>to exist. Surely we've missed some, but it's alright to not be fully<br>exhaustive.<br><br>In this next round, I want us to give our opinion, on each of these<br>use-cases, on whether we believe that this use-case is best served by<br>extension. My goal, in this round, is not necessarily to build<br>consensus for a policy, but to discover where there is consensus, and<br>where there is controversy, so that we can discuss the relevant<br>use-cases in more detail.<br><br>In this round, I'm asking you, for each X∈{1,…,13}, to answer the<br>following questions:<br><br>X.1: do you believe that this a use-case that GHC should support? (yes/no)<br>X.2: regardless of your answer in X.1, if GHC supports this use-case,<br>  do you believe that this use-case is best served by extensions. (yes/no)<br>X.2.Y: Do you believe that GHC20xx helps support this use-case (yes/no)<br>X.2.N: if you've answered “no” to X.2: what mechanism would you rather<br>  see supporting this use-case (free form)<br><br>I'll be on holiday next week, and will tally the results on the first<br>week on May.<br><br>The 13 use-cases are<br><br>1. Gain early access to experimental or unstable features<br>   (e.g. because they're working on a research prototype, or because<br>   the feature is valuable enough to them to forgo some stability)<br>2. Restrict the use of more complex features (e.g. for easier<br>   onboarding of new developers or as educators to teach a<br>   well-delimited subset of the language)<br>3. Restrict the use of novel features since the last established<br>   standard/report.<br>4. Restrict the use to features that they don't like (e.g. controversial<br>   features like RecordWildcard or ImplicitParameters)<br>5. Name/refer to a particular feature when talking/writing/searching<br>   about it.<br>6. Restrict the use of features which require support from outside<br>   the Haskell ecosystem that can't be taken for granted (I think this<br>   concerns only UnicodeSyntax)<br>7. As library authors, to signal which features the library actually<br>   uses, hence which version of GHC the library is compatible with.<br>8. Retain access to deprecated features to smooth out migration over<br>   the deprecation period.<br>9. Retain access to deprecated features indefinitely.<br>10. Change the default behaviour of (part of) the language<br>    (e.g. StrictData, I think some of the dependent Haskell work falls<br>    in this category, but I can't pinpoint an example)<br>11. Extend the language in a way that is not backward compatible<br>    (e.g. OverloadedList, probably some dependent Haskell things too)<br>12. Enable features whose mere presence has a performance impact<br>    (e.g. Template Haskell, and that's probably it)<br>13. CPP (this one is very unique isn't it?)</div>