<div dir="ltr"><div>While I'm typing my next round of questions, and based on the feedback in this thread, here is the list of use-cases that I could gather.</div><div><br></div><div>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?)<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 17 Apr 2023 at 09:02, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>(sorry, it's been a busy week, next email thread comes out today, or tomorrow at the latest)<br></div><div><br></div><div>Joachim: <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">From a user-point of view, it seems you could possible merge 1, 4, 5,<br>
6, 7 and 8 as “Developer wants access to features not on by default”.<br>
The developer probably doesn’t really care _why_ the extension is not<br>
on by default, they just want to use it when they want to use it :). <br></blockquote><div><br></div><div>At the end of the day, an extension is either a feature that is off by default and can be turned on, or on by default and can be turned off. I don't think we've said much when we've reduced the users' behaviour to that level. So I wanted this list to be specifically about the why. And I think the users do care. GHC Proposals say “I want a new extension to support X”, I wanted to be as exhaustive as possible to then be able to try and then delineate the X-s that we intend language extensions to support.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 7 Apr 2023 at 17:33, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><span style="color:rgb(0,0,0);font-family:-webkit-standard;font-size:medium">As Joachim says, "</span><span style="color:rgb(0,0,0)">Programmers use extensions to _refer_ to a particular feature</span><span style="color:rgb(0,0,0)"> when talking/writing/searching about it."</span><div style="color:rgb(0,0,0)"><font color="#000000"><br></font></div><div style="color:rgb(0,0,0)"><font color="#000000">I think this is generally important. The language reports provide the foundations for understanding the language and it is important to have a handle to describe the various departures from it -- at least until a new report around which near universal acceptance can be established. </font></div><div style="color:rgb(0,0,0)"><font color="#000000"><br></font></div><div style="color:rgb(0,0,0)"><font color="#000000">I would extend "</font>2. Restrict the use of more complex features" to say <font color="#000000">"</font>2. Restrict the use of _novel_ and more complex features". I think many just want to say exactly how they are departing from Haskell 2010, whether those deltas are complex or otherwise.</div><div style="color:rgb(0,0,0)"><font color="#000000"><br></font></div><div style="color:rgb(0,0,0)"><font color="#000000">Chris <br></font></div><br></div></blockquote></div>
</blockquote></div>