[ghc-steering-committee] GHC2021: DeriveAnyClass

[Joachim Breitner]

Am Dienstag, den 01.12.2020, 08:14 +0000 schrieb Simon Peyton Jones via
ghc-steering-committee:
> There are lots of “deriving” extensions.  I treated them as a group,
> but you could perhaps argue that doing so isn’t right. Is there a
> reason to choose one over the others to be in the on-by-default set? 

I think so!

There are extensions like DerivingVia or StandaloneDeriving that come
with new, obvious syntax. These, like many other, have the property
that you can see that they are being used because, well, they are being
used, and requiring the user to write the language extension explicitly
isn’t so useful.

Then there are those that are less visible, but totally harmless and a
natural continuation of what we have, namely more stock deriving
extensions (DerivingFunctor, etc.).


For all those above, even someone who isn't intimately acquainted with
the extensions will not be thrown off when reading it; for the first
group they will see something they don’t know and can read about it.
For the second group… there isn’t even anything to think about, it does
what you think it does.

And then there are those that do “implicit magic”, in particular
DeriveAnyClass. Here, an unsuspecting reader might fully understand
what’s going on.

Worse: With this extension on by default, beginners might try to put
MyCustomClass into their deriving set, and get very unhelpful error
messages:

   Prelude> class Test a where test :: a
   Prelude> data Foo = Foo deriving Test

   <interactive>:4:25: error:
       • Can't make a derived instance of ‘Test Foo’:
           ‘Test’ is not a stock derivable class (Eq, Show, etc.)
           Try enabling DeriveAnyClass
       • In the data declaration for ‘Foo’
   Prelude> :set -XDeriveAnyClass 
   Prelude> data Foo = Foo deriving Test

   <interactive>:6:25: warning: [-Wmissing-methods]
       • No explicit implementation for
           ‘test’
       • In the instance declaration for ‘Test Foo’

   With my (past) educator’s hat on, given that error messages, I say
   “please no!”.

   And with my Haskell author’s head on, I say “Lets get away from
   DeriveAnyClass and move to using deriving via to _explicitly_ say
   what’s going on here”.

   I have absolutely no qualms like this about the other Deriving
   extensions.

   Cheers,
   Joachim


   -- 
   Joachim Breitner
  mail at joachim-breitner.de
  http://www.joachim-breitner.de/