[ghc-steering-committee] Language Extension Policy – Round 1'

[Simon Peyton Jones]

Thanks Arnaud.  I'm not sure of the use to which you plan to put this list
- but it seems like a reasonable starting point.

S

On Thu, 30 Mar 2023 at 10:04, Arnaud Spiwack <arnaud.spiwack at tweag.io>
wrote:

> 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
> _______________________________________________
> 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/20230330/b23609fd/attachment.html>