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

[Eric Seidel]

Thanks for reminding me again of this proposal, plugins actually came to my mind as well when I was writing my recommendation for Mario's proposal.

- The barrier to entry is significantly raised with a plugin, both for authors and users. This is likely fine for the purpose of experimentation, but I think we should be clear that plugins are not a long-term solution here. 
- The flip side of the above is that we're not at all tied to any particular design in the interim.
- The plugin API neatly provides a way to "export" defaulting rules, but it doesn't really seem to address the conflict-resolution aspect of Mario's proposal. If I enable multiple defaulting plugins with conflicting rules, how does defaulting work? Presumably it boils down to the order in which the plugins are installed, and I either have to manage that or write my own plugin, both of which seem painful. Mario's solution of writing another defaulting rule in the current module is much cleaner, and *more likely to actually see use*.
- So I'm worried that a defaulting plugin API will be unwieldy enough that we won't see much experimentation in exactly the area I want to see experimentation, how do we share defaulting rules and resolve conflicts.
- Could we write a *generic* defaulting plugin that would allow sharing user-defined rules? Maybe, I can kind of imagine how you could write dummy values that the plugin interprets as defaulting rules, and which can then be exported and imported as usual. I think that's an intriguing idea that might be lightweight enough to see use and let us experiment with different rules around sharing, coherence, and conflict resolution.

Eric

On Wed, May 19, 2021, at 12:17, Richard Eisenberg wrote:
> How does this proposal compare to 
> https://github.com/abarbu/ghc-proposals/blob/master/proposals/0000-defaulting-plugins.rst ? That alternative proposal was ruled "out of scope", because it describes a plugin interface, which is out of scope of this committee. But I think it's a viable alternative to Mario's proposal here, and appears to be more powerful (although more difficult to use). I'm worried that the "out of scope" label derailed the plugins proposal, as I do not believe that further work on that idea (even though it's already implemented!) has been pursued.
> 
> Richard
> 
> > On May 18, 2021, at 10:11 PM, Eric Seidel <eric at seidel.io> wrote:
> > 
> > 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
>