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

Tue Jun 8 17:16:23 UTC 2021

Thanks for this summary!

As I've argued on GitHub, I feel quite strongly against silent importing of defaulting, where "silent" means that code that compiles today might continue to compile tomorrow, but with defaults imported. Route (1) in Eric's email describes the need for a new extension to allow default imports. This avoids my problem with "silent", but I don't really like it. Route (2) is most natural in its "silent" mode (as Eric argues), but I really really don't want silent mode! So my ideas on GitHub are a bit funny-shaped. I would love if someone could come up with a better solution to this all, that avoids silence while still not being as awkward as my ideas on GitHub.

All that said, I won't die on this hill, if the rest of the committee opts for a choice that allows silent default imports. Maybe I'd be happy enough with a warning (on by default) that a default was silently imported; users could suppress the warning by making the default import explicit. Perhaps even better (more precise) would be a warning when a default was silently imported and a constraint of the class of the default-import were defaulted. (It might be hard to say whether the import actually changed the defaulting behavior, so I won't ask for that. It would be enough just to know that an import was about the same class as the defaulting was.) Actually, this might be the middle road we can all like.

Richard

> On Jun 6, 2021, at 11:14 PM, Eric Seidel <eric at seidel.io> wrote:
> 
> 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