Stand-alone deriving declarations added
bringert at cs.chalmers.se
Fri Oct 6 04:23:44 EDT 2006
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
> | 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
> | 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
deriving Data Person, Typeable Person, Data Team, Typeable Team
deriving Data Department, Typeable Department, Data Company, Typeable
More information about the Cvs-ghc