<div dir="ltr"><div dir="ltr">On Fri, 22 Mar 2024 at 18:27, Simon Peyton Jones <<a href="mailto:simon.peytonjones@gmail.com">simon.peytonjones@gmail.com</a>> wrote:</div><div class="gmail_quote"><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"><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">

I really want ghci to use the latest and greatest language edition.<br></blockquote><div><br></div><div style="font-family:tahoma,sans-serif">I think we agree about this</div><div style="font-family:tahoma,sans-serif"><br></div><blockquote class="gmail_default gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
I also would prefer it to be used when calling ghc on a quick test file.<br>
If deemed necessary we can throw a warning when we fallback to a default in<br>
that case.

</blockquote><div><br></div><div style="font-family:tahoma,sans-serif">Ah, but now we are on the slippery slope.  Your "quick test file" may well become a little script you use every day... and it may then suddenly stop working when you install a new GHC with a new default language edition.  We don't want that!  And it is completely solved by saying that we never change the default language edition for .hs modules -- if it works now it'll work in the future because we always fall back to the same language edition. (e.g Hsakell98 or GHC2021 or whatever). </div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">In some ways Hakell98 is better: it's very stable; and it is so old that it'll encourage you to put a one-line {-# LANGUAGE GHC2024 #-} at the top of your module to make it self-describing.   I love self-describing files :-)<br></div></div></blockquote><div><br></div><div>I can think of a couple of reasons not to fix the default language permanently:</div><div><ul><li>Eventually we'll want to remove support for Haskell98, GHC2021 etc. because supporting old versions of the language gets harder over time. The Fortified Language Editions proposal requires 3 years of support only. (indeed Haskell98 is already not really Haskell98, because the definition of Monad has changed for example)</li><li>Other languages don't do it this way, e.g. with gcc/g++ you get some recent version of C/C++ by default.<br></li></ul><div>Cheers</div><div>Simon<br></div></div><div> </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 style="font-family:tahoma,sans-serif"></div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">I wonder if this debate would be better on the GitHub discussion thread?  I'd love to hear from more people.</div><div style="font-family:tahoma,sans-serif"><br></div><div style="font-family:tahoma,sans-serif">Simon<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, 22 Mar 2024 at 14:42, Malte Ott <<a href="mailto:malte.ott@maralorn.de" target="_blank">malte.ott@maralorn.de</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 also think that the notion of default-language matters. For some reason people<br>
care greatly about which is the "real" Haskell.<br>
<br>
I really want ghci to use the latest and greatest language edition.<br>
I also would prefer it to be used when calling ghc on a quick test file.<br>
If deemed necessary we can throw a warning when we fallback to a default in<br>
that case.<br>
<br>
I think it is very important that we care about breakage for the sake of the<br>
ecosystem. But the ecosystem relies on Cabal to build packages so outside of<br>
that changes have another quality.<br>
<br>
Best<br>
Malte<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>
_______________________________________________<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>