Request for feedback: deriving strategies syntax

[Ryan Scott]

> How much of this derivation machinery could NOT be implemented by means of
> some kind of a (hypothetical) type-backed metaprogramming facility?

I think this would be a wonderful thing to have. Matthew Pickering
(cc'd) has expressed a desire to have all the logic for the `bespoke`
deriving strategies compartmentalized into a library that could easily
be expanded on in the future to support more typeclasses in base.
(Bifunctor, anyone?)

Unfortunately, each of the major players in today's Haskell
metaprogramming scene that I'm aware of have some downfalls that make
them unsuitable as `deriving` replacements:

* Template Haskell: Not portable. Staging issues make it hard to use
as a drop-in replacement for the `deriving` keyword
* GHC generics: Can't express all the optimizations that the bespoke
`deriving` algorithms perform. Unperformant.
* Haskell preprocessors: Difficult to integrate in a typical GHC
workflow. Probably wouldn't have all the metadata you'd need to be
feature-complete with what `deriving` does today.

The way I see it, the whole `deriving` business as it currently stands
today is a somewhat-grotesque-but-darn-useful hack that gets around
the lack of a truly nice metaprogramming facility in Haskell. I'm
holding out hope that the work in
https://github.com/shayan-najd/NativeMetaprogramming makes things
nicer soon, and then we can revisit this idea. Until then,
-XDerivingStrategies provides a way to contain some of the madness of
`deriving` after having many features tacked onto it in recent GHC
releases.

Ryan S.