[ghc-steering-committee] Why not?, rather than, why?

[Arnaud Spiwack]

Personally, my concern is primarily procedural. There is no official stance
on what an extension can be, so different people map different concepts on
them. As a result, we have a lot of conversations (in here, in proposal
threads) where everybody speaks past one another. What I would like is that
we come together and design a principle saying: we strive for future
extensions to be X. This would clarify discussions around
- Is a new extension X appropriate?
- Should extension X imply extension Y?
- Should extension X be included in GHC20XX?

My personal (strong) preference is for striving for extensions to either
become a default, eventually, or to be deprecated. It also seems to be the
preference of most of those who spoke up here. But what really matters is
that we make a choice. The choice can be: “An extension is a switch that
triggers optional behaviour in the language, it can be used to gate
advanced features, some (but probably not all) of these extensions will
become defaults if their use is generalised enough”, I'd disagree with the
choice, but I'd champion it anyway. Note that this option is compatible
with the no-language-fork principle.

My point is: we need to take an explicit stance and record it.

/Arnaud

On Mon, 5 Dec 2022 at 22:03, Chris Dornan <chris at chrisdornan.com> wrote:

> Now I am sorry — my tongue was in my cheek in talking about the thread
> taking an authoritarian turn!
>
> I think we can al agree that there is a cost to adding more and more
> extensions, and bear the mounting complexity in mind when scrutinising
> these proposals, and try to steer this review process towards a coherent
> future language. At least that is my understanding of the spirit of what
> Joachim is getting at when he initiated this thread, in which case count me
> in. My point is just that we don’t also forget certain necessary messy
> realities in attempting to unwind ourselves from the ‘excessive’ complexity
> that our open, experimental philosophy/DNA will tend to generate.
>
> I would love to here more from Simon venting on what needs to happen,
> ideally down the pub, but, more practically, we might have to make do with
> a virtual one…
>
> Chris
>
>
> On 5 Dec 2022, at 19:03, Simon Marlow <marlowsd at gmail.com> wrote:
>
> Apologies, I didn't mean to sound like I wanted us to be "authoritarian",
> perhaps more along the lines of "opinionated". By analogy with the CLC:
> they are forced to make decisions, because there is only one set of core
> libraries. I don't necessarily agree with all the decisions that the CLC
> makes, but I'm very glad we only have one set of core libraries.
>
> In GHC we have the dubious luxury of being able to give people optional
> language features, I'm suggesting we should use this very carefully and
> avoid forks - which is our current policy anyway - but to be more
> intentional about it in the way that Joachim suggested. I'm also a fan of
> an open platform that encourages experimentation, but at some point we have
> to accept (I believe) that too much of this leads to a poor experience for
> new users. (that's putting it gently! I'm itching to rant about this some
> more, but I fear it may come across poorly. One for the pub.)
>
> Cheers
> Simon
>
> On Fri, 2 Dec 2022 at 19:04, Chris Dornan <chris at chrisdornan.com> wrote:
>
>> I think we are on the same page, but the thread seemed to be taking an
>> authoritarian turn so I thought it best to ensure the voices of caution
>> were represented!
>>
>> Chris
>>
>> > On 2 Dec 2022, at 17:39, Joachim Breitner <mail at joachim-breitner.de>
>> wrote:
>> >
>> > Hi,
>> >
>> > Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:
>> >> I am sympathetic to the idea of a new language standard that we
>> >> promote heavily and encourage developers, tools, tutorials and
>> >> courseware to favour —if we get this right then we will reap the
>> >> benefits of a strong standard. But if we take it upon ourselves to
>> >> try and force an extension combination of our choosing on the
>> >> community because we believe the community will benefit from a big
>> >> reset then I think it could blow up on us really badly, with forks
>> >> and factions which could be truly difficult to manage — and fatally
>> >> discourage adoption.
>> >
>> > ah, sorry if I was unclear. I am certainly not proposing a form of “big
>> > reset”!  It’s more about “should every language extension be in
>> > principle on track towards in inclusion to a future GHC20xx” – still
>> > all incremental and cautious.
>> >
>> > Cheers,
>> > Joachim
>> >
>> > --
>> > Joachim Breitner
>> >  mail at joachim-breitner.de
>> >  http://www.joachim-breitner.de/
>> >
>> > _______________________________________________
>> > ghc-steering-committee mailing list
>> > ghc-steering-committee at haskell.org
>> >
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>> _______________________________________________
>> ghc-steering-committee mailing list
>> ghc-steering-committee at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
>
> _______________________________________________
> 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/20221208/75f01ac0/attachment-0001.html>