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