<html><body><div dir=""><div dir="ltr">
Hi everybody,</div><div dir="ltr"><br></div><div dir="ltr">The discussion in the PR has also convinced me about the advantages of being able to import/export defaults.</div><div dir="ltr"><br></div><div dir="ltr">I would like to add that there’s a in-the-middle option discussed somewhere in the PR, which is (1) + a way to hide the defaulting. Something like:</div><div dir="ltr"><br></div><div dir="ltr">> import Module hiding (default Num)</div><div dir="ltr"><br></div><div dir="ltr">which I find quite natural: everything related to type classes is imported automatically, and “defaulting” goes in that “mental bucket” for me.</div><div dir="ltr"><br></div><div dir="ltr">Another concern for me is the requirement of having 3 different extensions. I know being fine-grained is great, but I think we’ve erred sometimes in the “too much” side in the past. I’ve written in the PR on that matter.</div><div dir="ltr"><br></div><div dir="ltr">Regards,</div><div dir="ltr">Alejandro</div><div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">El 7 jun 2021 5:14:55, 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>
The response to the NamedDefaults extension has been uniformly positive, so I think we can consider that part accepted.<br><br>However, we still need to make a decision about the ExportedDefaults extension. Since my original recommendation to reject this part of the proposal, I've come around to the argument that defaulting rules don't need global coherence like class instances, so explicit exports are fine. Simon PJ and Richard have also voiced support for explicit exports as suggested in the proposal.<br><br>So I would like to revise my recommendation for ExportedDefaults to *accept*.<br><br>That leaves the question of how defaulting rules should be imported. The two options are<br><br>1. *implicit*: all defaulting rules exported by a module M are automatically imported by *any* import of M, just like class instances. The proposal suggests doing this, and hiding it behind an `ImportedDefaults` extension, which feels unnecessary to me.<br><br>2. *explicit*: defaulting rules must be explicitly imported, using a syntax like `import M (default C)`. If we go this route, we will also need to decide whether a plain `import M` should import defaulting rules. Richard argues on GitHub that it should not, but I think that veers too far from the existing behavior of imports.<br><br>Between the two, I lean towards (2) for the symmetry between explicit exports and imports, with the `import M` syntax pulling in defaulting rules.<br><br>Eric<br><br><br>On Tue, May 25, 2021, at 16:01, Richard Eisenberg wrote:<br><blockquote type="cite"> I have commented on GitHub with my thoughts here: <br></blockquote><blockquote type="cite"> <a href="https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-848221001">https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-848221001</a><br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> Thanks,<br></blockquote><blockquote type="cite"> Richard<br></blockquote><blockquote type="cite"> <br></blockquote><blockquote type="cite"> > On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena <<a href="mailto:trupill@gmail.com">trupill@gmail.com</a>> wrote:<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > Hi all,<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > 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.<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > Alejandro<br></blockquote><blockquote type="cite"> > <br></blockquote><blockquote type="cite"> > El 19 may 2021 4:11:48, Eric Seidel <<a href="mailto:eric@seidel.io">eric@seidel.io</a>> escribió:<br></blockquote><blockquote type="cite"> >> Hi all,<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> Mario has proposed a handful of language extensions around type defaulting.<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> 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></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> 2. ExportedDefaults: this extension allows exporting defaulting rules.<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> 3. ImportedDefaults: this extension makes import declarations pull in defaulting rules implicitly, like class instances.<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> 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></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> My recommendation is that we<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> * Accept extension (1), as it is a clear improvement over the status quo and can stand on its own.<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> * 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></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> Please take a look at the proposal.<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> Discussion: <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"> >> 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></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> Eric<br></blockquote><blockquote type="cite"> >> <br></blockquote><blockquote type="cite"> >> On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:<br></blockquote><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><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><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>