<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 September 2017 at 14:28, Joachim Breitner <span dir="ltr"><<a href="mailto:mail@joachim-breitner.de" target="_blank">mail@joachim-breitner.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
the vote seems to indicate acceptance so far; fine with me.<br>
<span class=""><br>
Am Donnerstag, den 21.09.2017, 08:46 +0100 schrieb Simon Marlow:<br>
> However, if we do accept the proposal, it should have its own<br>
> extension rather than being part of ExplicitNamespaces, for the<br>
> reasons discussed earlier: code needs a way to declare that it is<br>
> using a new extension, so that it can properly be rejected by older<br>
> versions of the compiler that don't support the extension.<br>
<br>
</span>Earlier we discussed the question of whether we want to allow minor<br>
changes to unextendd Haskell without extensions (and the consensus was<br>
no). This does not imply that we forbid ourselves from extending the<br>
range of existing GHC language pragmas.<br>
<br>
>From a user point of view, having “ExplicitNamespaces” allow me to<br>
explicitly name the namespaces of an identifier in identifier lists<br>
such as export, import and fixity lists is very natural. It would be<br>
strange if I need “ExplicitNamespaces” for export and import lists, but<br>
“ExplicitNamespacesFixities” in fixitiy lists.<br>
<br>
I am sure others can give concrete examples where the syntax of<br>
language extensions has evolved without introducing a wealth of new<br>
extensions (and having to support all combinations). TemplateHaskell<br>
splices maybe? RebindableSyntax maybe?<br></blockquote><div><br></div><div>It's a tradeoff and we could go either way, but I'll argue for being strict here. Suppose we have some code that uses the new extension and I compile it with GHC 8.2. The choice is between:</div><div><br></div><div>* without a new extension flag, GHC says "Parse error"</div><div>* with a new extension flag, GHC says "Extension not supported", and in fact we might not even get that far because our tooling might tell us that we can't compile this code before we even try. Or Cabal could choose a different (and supported) version of the package instead.</div><div><br></div><div>It's a choice between having metadata and a bit of extra work, vs. having no metadata and things sometimes failing.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
So is there a sensible way we can avoid fringe language extension<br>
pragma proliferation?<br></blockquote><div><br></div><div>yes there is, it's called Haskell Prime :)</div><div><br></div><div>Cheers</div><div>Simon</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Joachim<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
--<br>
Joachim Breitner<br>
  <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br>
  <a href="http://www.joachim-breitner.de/" rel="noreferrer" target="_blank">http://www.joachim-breitner.<wbr>de/</a><br>
</div></div><br>______________________________<wbr>_________________<br>
ghc-steering-committee mailing list<br>
<a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@<wbr>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-<wbr>bin/mailman/listinfo/ghc-<wbr>steering-committee</a><br>
<br></blockquote></div><br></div></div>