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

[Simon Peyton Jones]

>
> The choice can be:...
> My point is: we need to take an explicit stance and record it.
>

Do you want to lay out
* the problem you want to solve
* a set of possible choices that might solve it

Personally I don't perceive an immediate problem that we need to solve.
But I'm an outlier and willing to be educated.



On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack <arnaud.spiwack at tweag.io> wrote:

> 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
>>
> _______________________________________________
> 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/1ecbf1b9/attachment-0001.html>