Proposal: Add `Generically` (or `WrappedGeneric`) newtype to GHC.Generics

[Oliver Charles]

Thanks for suggesting the Alexis, I've been thinking about exactly the same
thing, albeit for other generics libraries. It would be great to have this
in GHC.Generics. I'm a +1.

I haven't really thought it out, but I wonder if

newtype GenericallyUsing a c

Also works, paving the way for other generic classes. This would let you
write

data Foo = Bar X | Baz Y Z
  deriving C via Foo `GenericallyUsing` GHC.Generics.Generic

But you could also swap in SOP. This does mean instances of
GenericallyUsing would probably need Flexible instances though, and it does
complicate things.

Just throwing that out there!

Ollie

On Fri, 30 Aug 2019, 7:18 pm David Feuer, <david.feuer at gmail.com> wrote:

> That is an absolutely *beautiful* idea. I love it to pieces. I'm not fussy
> about the name, but Generically does have a nice ring to it.
>
> On Fri, Aug 30, 2019, 2:16 PM Alexis King <lexi.lambda at gmail.com> wrote:
>
>> Hi all,
>>
>> In recent years, the DefaultSignatures extension has seen popular use as
>> a mechanism for providing derived typeclass instances via GHC.Generics.
>> Although undeniably useful, I have always felt it is somewhat ugly: it is
>> mutually exclusive with other, non-Generic default method implementations,
>> and it can only be used for one Generic deriving mechanism, so
>> implementations must choose between GHC.Generics and Data.Data.
>>
>> Fortunately, with the advent of DerivingVia, there is a better way:
>> simply attach generic instances to a separate newtype, defined like
>>
>> newtype Generically a = Generically { unGenerically :: a }
>>
>> instance Generic a => C (Generically a) where
>>   ...
>>
>> then derive instances using DerivingVia as follows:
>>
>> data Foo = Bar X | Baz Y Z
>>   deriving C via Generically Foo
>>
>> The `Generically` name already exists for this purpose in the
>> `generic-data` package, making it a good candidate name for a newtype in
>> GHC.Generics (`generic-data` could simply re-export the type with suitably
>> recent versions of `base`). An alternate name would be the more traditional
>> `WrappedGeneric`. I don’t have much of a preference either way, but I do
>> think the `Generically` name is cute, especially when used with DerivingVia.
>>
>> I believe this type should be in `base` because it is
>>
>> (1) clearly generally useful in the same way that similar newtypes in
>> `base` like `WrappedMonad` are (and probably even more so),
>>
>> (2) extremely lightweight in terms of additional API complexity (it’s
>> just a newtype),
>>
>> (3) isn’t worth depending on a separate package for, encouraging a
>> proliferation of (possibly name-conflicting) newtypes in individual
>> packages if it isn’t in `base`, and
>>
>> (4) is an opportunity to add instances based on `Generic` for classes
>> already in `base`.
>>
>> Overall, it’s something that would feel right at home in GHC.Generics to
>> me.
>>
>> As a final note, whichever name people prefer, it would of course make
>> sense to provide an analogous `Generically1` or `WrappedGeneric1` type for
>> `Generic1` (as `generic-data` does as well).
>>
>> Alexis
>> _______________________________________________
>> Libraries mailing list
>> Libraries at haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>>
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20190830/474a13f6/attachment.html>