Re: [ghc-steering-committee] #409: Exportable named defaults, Recommendation: Partial Accept

7 Jun 2021

      Hi everybody,

The discussion in the PR has also convinced me about the advantages of
being able to import/export defaults.

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:
...
import Module hiding (default Num)
which I find quite natural: everything related to type classes is imported
automatically, and “defaulting” goes in that “mental bucket” for me.

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.

Regards,
Alejandro

El 7 jun 2021 5:14:55, Eric Seidel  escribió:
...
The response to the NamedDefaults extension has been uniformly positive,
so I think we can consider that part accepted.
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.
So I would like to revise my recommendation for ExportedDefaults to
*accept*.
That leaves the question of how defaulting rules should be imported. The
two options are
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.
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.
Between the two, I lean towards (2) for the symmetry between explicit
exports and imports, with the `import M` syntax pulling in defaulting rules.
Eric
On Tue, May 25, 2021, at 16:01, Richard Eisenberg wrote:
I have commented on GitHub with my thoughts here:
https://github.com/ghc-proposals/ghc-proposals/pull/409#issuecomment-8482210...
Thanks,
Richard
...
On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena 
wrote:
...
...
Hi all,
...
...
I agree with the recommendations of accepting (1) and rejecting (2) and
(3). The Report here (
https://www.haskell.org/onlinereport/haskell2010/haskellch4.html#x10-790004....)
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.
...
...
Alejandro
...
...
El 19 may 2021 4:11:48, Eric Seidel  escribió:
...
...
Hi all,
...
...
...
...
Mario has proposed a handful of language extensions around type
defaulting.
...
...
...
...
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.
...
...
...
...
2. ExportedDefaults: this extension allows exporting defaulting rules.
...
...
...
...
3. ImportedDefaults: this extension makes import declarations pull in
defaulting rules implicitly, like class instances.
...
...
...
...
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.
...
...
...
...
My recommendation is that we
...
...
...
...
* Accept extension (1), as it is a clear improvement over the status
quo and can stand on its own.
...
...
...
...
* 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.
...
...
...
...
Please take a look at the proposal.
...
...
...
...
Discussion: https://github.com/ghc-proposals/ghc-proposals/pull/409
...
...
Proposal:
https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...
...
...
...
...
Eric
...
...
...
...
On Sun, Apr 4, 2021, at 06:34, Joachim Breitner wrote:
...
...
...
Dear Committe,
...
...
...
...
...
...
Exportable named defaults
...
...
...
has been proposed by Mario
...
...
...
https://github.com/ghc-proposals/ghc-proposals/pull/409
...
...
...
https://github.com/blamario/ghc-proposals/blob/exportable-named-default/prop...
...
...
...
...
...
...
I propose Eric as the Shepherd.
...
...
...
...
...
...
This did not gather a lot of attention on Github, or rather none, so
...
...
...
Eric, maybe also consider whether this needs to be advertised more, or
...
...
...
maybe who should be pointed to it.
...
...
...
...
...
...
Please guide us to a conclusion as outlined in
...
...
...
https://github.com/ghc-proposals/ghc-proposals#committee-process
...
...
...
...
...
...
Thanks,
...
...
...
Joachim
...
...
...
--
...
...
...
--
...
...
...
Joachim Breitner
...
...
...
mail@joachim-breitner.de
...
...
...
http://www.joachim-breitner.de/
...
...
...
...
...
...
...
...
...
_______________________________________________
...
...
...
ghc-steering-committee mailing list
...
...
...
ghc-steering-committee@haskell.org
...
...
...
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
...
...
...
...
...
_______________________________________________
...
...
ghc-steering-committee mailing list
...
...
ghc-steering-committee@haskell.org
...
...
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
...
_______________________________________________
...
ghc-steering-committee mailing list
...
ghc-steering-committee@haskell.org
...
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________
ghc-steering-committee mailing list
ghc-steering-committee@haskell.org
https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee