<html><body>
<div dir="ltr">
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.</div><div dir="ltr"><br></div><div dir="ltr">Alejandro</div><div dir="ltr"><br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On 1 Dec 2020 at 09:25:26, Joachim Breitner <<a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a>> wrote:<br></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div>
Am Dienstag, den 01.12.2020, 08:14 +0000 schrieb Simon Peyton Jones via<br>ghc-steering-committee:<br><blockquote type="cite"> There are lots of “deriving” extensions. I treated them as a group,<br></blockquote><blockquote type="cite"> but you could perhaps argue that doing so isn’t right. Is there a<br></blockquote><blockquote type="cite"> reason to choose one over the others to be in the on-by-default set? <br></blockquote><br>I think so!<br><br>There are extensions like DerivingVia or StandaloneDeriving that come<br>with new, obvious syntax. These, like many other, have the property<br>that you can see that they are being used because, well, they are being<br>used, and requiring the user to write the language extension explicitly<br>isn’t so useful.<br><br>Then there are those that are less visible, but totally harmless and a<br>natural continuation of what we have, namely more stock deriving<br>extensions (DerivingFunctor, etc.).<br><br><br>For all those above, even someone who isn't intimately acquainted with<br>the extensions will not be thrown off when reading it; for the first<br>group they will see something they don’t know and can read about it.<br>For the second group… there isn’t even anything to think about, it does<br>what you think it does.<br><br>And then there are those that do “implicit magic”, in particular<br>DeriveAnyClass. Here, an unsuspecting reader might fully understand<br>what’s going on.<br><br>Worse: With this extension on by default, beginners might try to put<br>MyCustomClass into their deriving set, and get very unhelpful error<br>messages:<br><br> Prelude> class Test a where test :: a<br> Prelude> data Foo = Foo deriving Test<br><br> <interactive>:4:25: error:<br> • Can't make a derived instance of ‘Test Foo’:<br> ‘Test’ is not a stock derivable class (Eq, Show, etc.)<br> Try enabling DeriveAnyClass<br> • In the data declaration for ‘Foo’<br> Prelude> :set -XDeriveAnyClass <br> Prelude> data Foo = Foo deriving Test<br><br> <interactive>:6:25: warning: [-Wmissing-methods]<br> • No explicit implementation for<br> ‘test’<br> • In the instance declaration for ‘Test Foo’<br><br> With my (past) educator’s hat on, given that error messages, I say<br> “please no!”.<br><br> And with my Haskell author’s head on, I say “Lets get away from<br> DeriveAnyClass and move to using deriving via to _explicitly_ say<br> what’s going on here”.<br><br> I have absolutely no qualms like this about the other Deriving<br> extensions.<br><br> Cheers,<br> Joachim<br><br><br> -- <br> Joachim Breitner<br> <a href="mailto:mail@joachim-breitner.de">mail@joachim-breitner.de</a><br> <a href="http://www.joachim-breitner.de/">http://www.joachim-breitner.de/</a><br><br><br>_______________________________________________<br>ghc-steering-committee mailing list<br><a href="mailto:ghc-steering-committee@haskell.org">ghc-steering-committee@haskell.org</a><br><a href="https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee">https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee</a><br>
</div>
</blockquote>
</div>
</div>
</body></html>