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

[Alejandro Serrano Mena]

 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 <eric at seidel.io> 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-848221001
>
>
> Thanks,
>
> Richard
>
>
> > On May 20, 2021, at 11:24 AM, Alejandro Serrano Mena <trupill at gmail.com>
> 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.3.4)
> 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 <eric at seidel.io> 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/proposals/0000-exportable-named-default.rst
>
> >>
>
> >> 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/proposals/0000-exportable-named-default.rst
>
> >>>
>
> >>> 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 at joachim-breitner.de
>
> >>>   http://www.joachim-breitner.de/
>
> >>>
>
> >>>
>
> >>> _______________________________________________
>
> >>> ghc-steering-committee mailing list
>
> >>> ghc-steering-committee at haskell.org
>
> >>>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> >>>
>
> >> _______________________________________________
>
> >> ghc-steering-committee mailing list
>
> >> ghc-steering-committee at haskell.org
>
> >>
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
> > _______________________________________________
>
> > ghc-steering-committee mailing list
>
> > ghc-steering-committee at haskell.org
>
> > https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20210607/d28b106a/attachment-0001.html>