<div dir="ltr">Dear all,<br><br>Sorry for the long silence. I was named and shamed by Joachim the<br>other day, which is fair enough. I've basically disappeared from my<br>email for a while. I am aware that not having solved this is holding<br>us back, I'll be more consistent in the future.<br><br>As I said in my last email, I'd like to start the conversation again<br>from the point of view of use-cases, as proposed by Adam, and see if<br>it helps us go forward. What I want to do, today, is to describe what<br>Haskell programmers have been using extension for. This is meant to be<br>purely a description, without judgement on whether the proposed<br>use-cases are good ideas. When the use-cases are listed, we'll turn to<br>which we want to support and how.<br><br>Without further ado, here is a list of use-cases, based on Adam's list<br>(my rephrasing), with additions by me. Haskell programmers use<br>extensions to:<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. As library authors, to signal which features the library actually<br>   uses, hence which version of GHC the library is compatible with.<br>4. Retain access to deprecated features to smooth out migration over<br>   the deprecation period.<br>5. Retain access to deprecated features indefinitely.<br>6. 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>7. Extend the language in a way that is not backward compatible<br>   (e.g. OverloadedList, probably some dependent Haskell things too)<br>8. Enable features whose mere presence has a performance impact<br>   (e.g. Template Haskell, and that's probably it)<br>9. CPP (this one is very unique isn't it?)<br><br><br>(Note: Adam proposed some use-cases which are not included here: using<br>extension to ensure stability (which is the contrapositive of 1), and<br>as a GHC dev, make features available to early adopters (which is the<br>dual of 1). I didn't include them because I consider that they are<br>contained in 1, but if you disagree, please argue otherwise)<br><br>Questions:<br>1. Have we missed some use-cases, if so describe? (I'm sure we have,<br>   so I'd be surprised if nothing turns up here)<br>2. Do you think some of the use-cases above should be split into<br>   several use-cases?<br>3. Conversely, are there distinctions that don't make sense to you and<br>   you would argue should be merged?<br><br>Before answering, take note that while some of the proposed use-cases<br>can be seen as a list of extensions that behave a certain way, some<br>extensions may be used in several use-cases (4 and 5, by definition<br>concern the same set of extensions), some use-cases (like 3) are<br>independent of the behaviour of extensions. This is not a<br>classification of extension, but of how they are consumed.<br><br>I'll tally the result on Tuesday 10th April.<br><br>Best,<br>Arnaud</div>