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

[Arnaud Spiwack]

👋

I see that this hasn't sparked a lot of discussion, I hope it means we're
finally finding some common ground that we agree is meaningful.

I said that I'd tally the result on “Tuesday 10th” in my initial email.
Turns out, the 10th is a Monday. As it's a bank holiday for me, the tally
will be Tuesday 11th, and you'll hear more from me a couple of days later.


On Tue, 4 Apr 2023 at 18:25, Simon Marlow <marlowsd at gmail.com> wrote:

> 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/20230407/b2f32138/attachment.html>