<html><body><div dir=""><div dir="ltr">
Hi all,</div><div dir="ltr"><br></div><div dir="ltr">I agree with the recommendations of accepting (1) and rejecting (2) and (3). The Report here (<a href="https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4">https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004.3.4</a>) mentions that defaults are local to a module, and I think this is the right move, even more so since we can think of other ways of importing/exporting defaults, like plug-ins.</div><div dir="ltr"><br></div><div dir="ltr">Alejandro<br><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El 19 may 2021 4:11:48, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> escribió:<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>
<div>
Hi all,<br><br>Mario has proposed a handful of language extensions around type defaulting.<br><br>1. NamedDefaults: this extension simply allows specifying the class to default, instead of it always being Num (or a handful of other hardcoded classes if one enables ExtendedDefaultRules). The rule only applies to the current module, as usual.<br><br>2. ExportedDefaults: this extension allows exporting defaulting rules.<br><br>3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.<br><br>Extensions (2) and (3) work together to provide a mechanism for sharing sets of defaulting rules across modules. It is possible to import conflicting sets of defaulting rules from different modules, in that case the conflict must be resolved manually by the importing module, with a new defaulting rule.<br><br>My recommendation is that we<br><br>* Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.<br><br>* Reject (without prejudice) extensions (2) and (3). These extensions bring considerable extra complexity and another orphan-like mechanism. There's an open question here of whether defaulting rules should be globally coherent like type classes, or if they're something different; the discussion has arguments for both sides. I'm not sure, and so I recommend we don't commit ourselves one way or the other for now. <br><br>Please take a look at the proposal.<br><br>Discussion: <a href="https://github.com/ghc-proposals/ghc-proposals/pull/409">https://github.com/ghc-proposals/ghc-proposals/pull/409</a><br>Proposal: <a href="https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst">https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst</a><br><br>Eric<br><br>On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:<br><blockquote type="cite"> Dear Committe,<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Exportable named defaults<br></blockquote><blockquote type="cite"> has been proposed by Mario<br></blockquote><blockquote type="cite"> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/409">https://github.com/ghc-proposals/ghc-proposals/pull/409</a><br></blockquote><blockquote type="cite"> <a href="https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst">https://github.com/blamario/ghc-proposals/blob/exportable-named-default/proposals/0000-exportable-named-default.rst</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> I propose Eric as the Shepherd.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> This did not gather a lot of attention on Github, or rather none, so<br></blockquote><blockquote type="cite"> Eric, maybe also consider whether this needs to be advertised more, or<br></blockquote><blockquote type="cite"> maybe who should be pointed to it.<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Please guide us to a conclusion as outlined in <br></blockquote><blockquote type="cite"> <a href="https://github.com/ghc-proposals/ghc-proposals#committee-process">https://github.com/ghc-proposals/ghc-proposals#committee-process</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Thanks,<br></blockquote><blockquote type="cite"> Joachim<br></blockquote><blockquote type="cite"> -- <br></blockquote><blockquote type="cite"> -- <br></blockquote><blockquote type="cite"> Joachim Breitner<br></blockquote><blockquote type="cite"> <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br></blockquote><blockquote type="cite"> <a href="http://www.joachim-breitner.de/">http://www.joachim-breitner.de/</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> _______________________________________________<br></blockquote><blockquote type="cite"> ghc-steering-committee mailing list<br></blockquote><blockquote type="cite"> <a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br></blockquote><blockquote type="cite"> <a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br></blockquote><blockquote type="cite"> <br></blockquote>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</div>
</blockquote>
</div>
</div></div></body></html>