Stand-alone deriving declarations added

[Bjorn Bringert]

On 6 okt 2006, at 09.41, Simon Peyton-Jones wrote:

> | I'd be much in favour of a story that make derivings at data/newtype
> | declarations simply syntactic sugar for a data/newtype declaration
> | without a deriving clause plus a couple of stand-alone deriving
> | declarations.
>
> Why not allow
>
> 	deriving StateMonad [tok] for Parser tok m

Yeah, I agree. I suggested this in response to Bulats question earlier.

> Or indeed more generally, why not nuke the 'for' and have
>
> 	deriving StateMonad [tok] (Parser tok m)
>
> That's what Iavor suggested, and it certainly is attractive.

It sure is.

> You wrote
>
> | 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.
>
> Well, it still is syntactically distinct ('deriving' instead of  
> 'instance')
>
> | These are some things that make deriving declarations different from
> | instance declarations:
> |
> | a) You can only derive instances for data types and newtypes.
> | b) For deriving declarations, the compiler figures out the
> | constraints, whereas the programmer writes them for instance
> | declarations.
> | c) 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.
>
> All true, but we could generate sensible error messages for all these.
>
> | d) 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.
>
> In a way it does not matter... what you need to know is that there  
> now *is* an instance for (C T1..Tn)
>
> 	
> | 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.
>
> I think I'd advocate this.  I agree with Manuel that it seems odd  
> to be nearly, but not quite, as powerful as the built-in mechanism.

Good points. The only remaining argument that I can see is then that  
it would make Greg Fitzgerald's suggestion to allow this:

deriving Data, Typable for Person, Team, Department, Company

difficult to do as far as I can see. Though we could still allow  
multiple derivings in one declaration, just not the cartesian product  
version above:

deriving Data Person, Typeable Person, Data Team, Typeable Team
deriving Data Department, Typeable Department, Data Company, Typeable  
Company

/Björn