On 7 okt 2006, at 16.44, Twan van Laarhoven wrote:
The main use for this seems to be when a module defining a data type lacks an instance you want, and for some reason you can't get the original module changed.
If you continue this line of reasoning: 1. The only reason a module can not be changed is that it is in some library as opposed to your own code. 2. The only instances that can be derived are for Prelude classes.
In for example GHC, this is not entirely true. GHC can derive instances of Typeable and Data, and more could be added in the future. Also, compilers could conceivably allow user-defined deriving.
3. These classes are already known in library modules, so they could have been derived there. 4. The fact that they are not unnecessarily reduces the usefulness of the library, and could therefore be considered a bug.
Existing libraries might not know about which classes future compiler versions can derive. Also, a library that wants to work with multiple compilers cannot have deriving classes for non-standard classes.
5. In fact, looking at the standard libraries, they already provide instances for all relevant Prelude classes.
There are plenty of libraries which are not standard libraries.
This leaves me to wonder what stand-alone deriving is actually good for, only newtypes?
I agree that it's not exactly something you will use every day, but when you do need it, it can save a lot of work. Imagine defining standard Show and Read, or Data and Typeable, instances manually for some rich family of data types. Besides, as Manuel pointed out, stand-alone deriving generalizes the current deriving clauses. Thus it can be seen as a way to remove an unnecessary restriction. /Björn