| 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
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. 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.
Simon
_______________________________________________
Cvs-ghc mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/cvs-ghc
