Proposal for stand-alone deriving declarations?

[Bjorn Bringert]

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