[ghc-steering-committee] GHC2021: DeriveAnyClass

[Richard Eisenberg]

My worry with DeriveAnyClass that a user might try to derive a class not intended for use with DeriveAnyClass. For instance:

> class Pretty a where   -- render something for users, not debuggers
>   ppr :: a -> String
>   ppr x = pprs [x]
> 
>   pprs :: [a] -> String
>   pprs xs = "[" ++ intercalate "," (map ppr xs) ++ "]"
> 
> instance Pretty a => Pretty [a] where
>   ppr xs = pprs xs
> 
> instance Pretty Int where
>   ppr n = show n
> 
> data T = MkT1 Int | MkT2 Bool
>   deriving Pretty

With -XDeriveAnyClass, this compiles without any warnings -- and it seems like something a user might plausibly attempt. Attempting to ppr (MkT1 5) yields an infinitely long string. A more knowledgeable user would have written a MINIMAL pragma in Pretty (or perhaps designed the class differently), but not all users are experienced. If, say, we required an explicit deriving strategy to use DeriveAnyClass, or required a MINIMAL pragma, then I would feel differently. As it is, I think the extension is potentially dangerous, as it can create unexpected runtime behavior without warnings.

Richard

> On Nov 30, 2020, at 2:42 PM, Alejandro Serrano Mena <trupill at gmail.com> wrote:
> 
> 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
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee