[ghc-steering-committee] GHC2021: DeriveAnyClass

[Simon Peyton Jones]

I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension.

I’m a great fan of Template Haskell, but I didn’t put it in the “on by default” category.

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?

Simon

From: ghc-steering-committee <ghc-steering-committee-bounces at haskell.org> On Behalf Of Alejandro Serrano Mena
Sent: 30 November 2020 19:42
To: ghc-steering-committee at haskell.org
Subject: [ghc-steering-committee] GHC2021: DeriveAnyClass

Dear all,
I’ve found as a surprise that several members of the Committee have voted against, or even marked as dangerous, the DeriveAnyClass extension. Given that I am a great fan of it, I would like to open the debate about the particular extension.

In my case, most of my uses are to derive ToJSON and FromJSON from the Aeson package. I find it very nice to be able to pack all the information about auto-derived instances in a small block, instead of including Eq and Show in the deriving block, and then a few empty instance declarations below. This is definitely mainly a aesthetic reason.

The other reason for adoption is that it makes classes such as Eq or Show less “special”, so one does not have to explain to beginners that some classes can be derived in this way, some others in that other way, and so on. So my other reason for inclusion would be a uniformity one.

Regards,
Alejandro
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20201201/1326dd03/attachment-0001.html>