Re: [ghc-steering-committee] GHC2021: DeriveAnyClass

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 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@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee