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

[Simon Marlow]

I don't disagree with any of that. Not entirely sure where we're going...
but sure :)

Anyway, I suspect that number 7 includes more things than it might seem, if
we're really strict about backwards compatibility. Several extensions steal
some syntax, whether it's just keywords or other symbols, that will cause
code that uses the new keyword to be rejected. Just picking a few at
random: RecursiveDo, Arrows, PatternSynonyms.

Indeed while poking around I noticed some bugs

Prelude> :set -XNoRoleAnnotations
Prelude> let x :: role

<interactive>:35:10: error: parse error on input ‘role’

Cheers
Simon

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/20230404/99653f91/attachment.html>