[ghc-steering-committee] GHC2021: DeriveAnyClass

Alejandro Serrano Mena trupill at gmail.com
Tue Dec 1 08:45:57 UTC 2020


 Thanks for the illuminating discussion! I’ve been convinced that we should
move away from DeriveAnyClass, and provide and start using ‘via
Generically’ instead. Which happily also gets rid of DefaultSignatures,
which I never liked due to the intimate bundling with the class declaration.

Alejandro

On 1 Dec 2020 at 09:25:26, Joachim Breitner <mail at joachim-breitner.de>
wrote:

> 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/
>
>
> _______________________________________________
> 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/20201201/055bd7d1/attachment.html>


More information about the ghc-steering-committee mailing list