Proposal for stand-alone deriving declarations?

Bjorn Bringert bringert at
Thu Oct 5 19:32:23 EDT 2006

Off-list, Greg Fitzgerald pointed out that:

> Those wanting to use the SYB library may want to write something  
> like this for every datatype in their heirarchy:
>    deriving Data, Typable for Person, Team, Department, Company

That seems like a useful extension to me, and the meaning is obvious.  
This would as far as I can tell not be possible (or at least not  
readable) without the "for".


On 5 okt 2006, at 20.58, Bjorn Bringert wrote:

> We considered that syntax, but decided against it. Stand-alone  
> deriving declarations are made to be as similar as possible to the  
> current deriving mechanism, rather than be similar to instance  
> declarations. The basic reason for maintaining a syntactic  
> distinction between instance declarations and deriving declarations  
> is to make the programmer aware of the restrictions of the deriving  
> mechanism.
> These are some things that make deriving declarations different  
> from instance declarations:
> - You can only derive instances for data types and newtypes.
> - For deriving declarations, the compiler figures out the  
> constraints, whereas the programmer writes them for instance  
> declarations.
> - In GHC, you can declare non-Haskell98 instances such as Eq (C X)  
> where X is a concrete type, but you can't do deriving for them.
> - When deriving instances of multi-parameter type classes (again  
> non-standard), the newtype for which the deriving is made must be  
> the last argument to the class. If the syntax were "deriving (Class  
> T1 ... Tn)", it might not be clear to the reader what type the  
> deriving is for.
> I can't see any technical reason not to do as you propose. One  
> advantage would be that it makes it possible to fully subsume GHC's  
> current deriving extensions (though there are other ways to do  
> this, see my recent e-mail to ghc-cvs). One slight disadvantage is  
> that it does require a bit more footwork in the compiler to figure  
> out which type to do the deriving for.
> /Björn
> On 5 okt 2006, at 19.58, Iavor Diatchki wrote:
>> Hello,
>> A question about the syntax:  would there be a problem if we made the
>> 'deriving' declaration look like an instance?  Then we would not need
>> the special identifier 'for', and also we have a more standard  
>> looking
>> notation.  I am thinking something like:
>> deriving Show SomeType
>> deriving Eq (AnotherType a)
>> -Iavor
>> On 10/5/06, Björn Bringert <bringert at> wrote:
>>> Simon Peyton-Jones wrote:
>>> > | What is not so nice is that you take a new keyword ('for'),  
>>> which is
>>> > | quite likely to have been used as a variable name in existing  
>>> code.
>>> > (Or
>>> > | does it work out to use one of the 'special' names here?)
>>> >
>>> > The latter is what Bjorn has done.  That is, 'for' is only  
>>> special in
>>> > this one context.  You can use it freely otherwise.  As I  
>>> understand it
>>> > anyway.
>>> Yes. There is even a "for" function somewhere in the libraries  
>>> (or was
>>> it the testsuite, can't remeber), which tripped up one of my early
>>> versions, before I had remembered to make "for" as a special ID  
>>> in the
>>> parser.
>>> > | I think it would be useful to write the proposal in complete  
>>> detail up
>>> > | on the Haskell' wiki.
>>> >
>>> > Yes please.  Bjorn?  (It may just be a qn of transcribing the user
>>> > manual stuff you have written.)
>>> Sure. It seems that I have to be on the committee to write to the  
>>> Wiki.
>>> Can I join it?
>>> /Björn
>>> _______________________________________________
>>> Haskell-prime mailing list
>>> Haskell-prime at
> _______________________________________________
> Haskell-prime mailing list
> Haskell-prime at

More information about the Haskell-prime mailing list