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