<div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="gmail_default" style="font-family:tahoma,sans-serif">
The choice can be:...
<div>My point is: we need to take an explicit stance and record it.</div>
</div></blockquote><div><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Do you want to lay out <br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">* the problem you want to solve</div><div style="font-family:tahoma,sans-serif" class="gmail_default">* a set of possible choices that might solve it</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default">Personally I don't perceive an immediate problem that we need to solve. But I'm an outlier and willing to be educated.</div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div><div style="font-family:tahoma,sans-serif" class="gmail_default"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 8 Dec 2022 at 17:30, Arnaud Spiwack <<a href="mailto:arnaud.spiwack@tweag.io">arnaud.spiwack@tweag.io</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>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</div><div>- Is a new extension X appropriate?</div><div>- Should extension X imply extension Y?</div><div>- Should extension X be included in GHC20XX?</div><div><br></div><div>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.</div><div><br></div><div>My point is: we need to take an explicit stance and record it.</div><div><br></div><div>/Arnaud<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 5 Dec 2022 at 22:03, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>Now I am sorry — my tongue was in my cheek in talking about the thread taking an authoritarian turn!<div><br></div><div>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.</div><div><br></div><div>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…</div><div><br></div><div>Chris</div><div><br><div><br><blockquote type="cite"><div>On 5 Dec 2022, at 19:03, Simon Marlow <<a href="mailto:marlowsd@gmail.com" target="_blank">marlowsd@gmail.com</a>> wrote:</div><br><div><div dir="ltr"><div dir="ltr"><div>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. <br></div><div><br></div><div>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.)<br></div><div><br></div></div><div>Cheers</div><div>Simon<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 2 Dec 2022 at 19:04, Chris Dornan <<a href="mailto:chris@chrisdornan.com" target="_blank">chris@chrisdornan.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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!<br>
<br>
Chris<br>
<br>
> On 2 Dec 2022, at 17:39, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>> wrote:<br>
> <br>
> Hi,<br>
> <br>
> Am Freitag, dem 02.12.2022 um 17:27 +0000 schrieb Chris Dornan:<br>
>> I am sympathetic to the idea of a new language standard that we<br>
>> promote heavily and encourage developers, tools, tutorials and<br>
>> courseware to favour —if we get this right then we will reap the<br>
>> benefits of a strong standard. But if we take it upon ourselves to<br>
>> try and force an extension combination of our choosing on the<br>
>> community because we believe the community will benefit from a big<br>
>> reset then I think it could blow up on us really badly, with forks<br>
>> and factions which could be truly difficult to manage — and fatally<br>
>> discourage adoption.<br>
> <br>
> ah, sorry if I was unclear. I am certainly not proposing a form of “big<br>
> reset”! It’s more about “should every language extension be in<br>
> principle on track towards in inclusion to a future GHC20xx” – still<br>
> all incremental and cautious.<br>
> <br>
> Cheers,<br>
> Joachim<br>
> <br>
> -- <br>
> Joachim Breitner<br>
> <a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a><br>
> <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.de/</a><br>
> <br>
> _______________________________________________<br>
> ghc-steering-committee mailing list<br>
> <a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
<br>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div></div>
</div></blockquote></div><br></div></div>_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org" target="_blank">ghc-steering-committee@haskell.org</a><br>
<a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee" rel="noreferrer" target="_blank">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</blockquote></div>