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

[Spiwack, Arnaud]

I’m catching up here.

Let me share a few thoughts:

   - I really want something like this (both for better OverloadedList
   support, and because it’s super useful in tests)
   - I’m rather unsure what to think about regarding the non-total priority
   (the fact that you can have default C (A, B); default D (B, A) and need
   to default a variable x with (C x, D x)). This sounds like something
   that must at least be specified. Am I correct that it isn’t?
   - There is no point in separating NamedDefaults and ExportedDefaults in
   two extensions
   - Regarding imports: in a first approximation explicit imports are
   useless. Having implicit imports lets me, for instance, define default
   IsList ([]) in the prelude, and then turn OverloadedList on in GHC2023
   and not break existing programs. Yay. Explicit default imports just save me
   one copy-paste. Note by the way that if GHC2023 is the target, then the
   extension to import defaults would also have to be included in GHC2023,
   so, basically, ImportedDefaults is practically useless, and we should
   just import defaults (I don’t think a warning would make much sense for a
   normal default behaviour; I agree with Simon that this is not worse than
   importing overloaded instances).

Still, there are some dark corners (I have pointed out one above, but I
also find the exports and imports kind of difficult to wrap my head
around). So I guess the conversation is not over quite yet.

On Wed, Jun 9, 2021 at 2:44 AM Eric Seidel <eric at seidel.io> wrote:

> On Tue, Jun 8, 2021, at 13:16, Richard Eisenberg wrote:
> > 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.
>
> I think a warning is very reasonable, but I'm not sure about turning it on
> by default.
>
> IMO, far and away the biggest use case for ExportedDefaults will be the
> myriad Prelude replacements (and maybe someday even the Prelude itself).
> For those use cases I think it's quite important that the import be a clean
> one-liner like
>
>   import MyPrelude
>
> rather than
>
>   import MyPrelude
>   import MyPrelude (default IsString, default Num, ...)
>
> For other random modules that want to export defaults I feel much less
> strongly about the single import. Maybe that's an argument for a more
> baked-in way of installing a custom Prelude.
>
> Eric
> _______________________________________________
> 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/20210611/93673fc8/attachment.html>