
| Why not even simply | | instance Typeable (T a) | | In other words, derivable classes define default | implementations for all their methods. But that has an existing meaning! It means "use the default methods for all methods of the class". Which is not the same as "derive all methods". It'd have to be instance Typeable (T a) deriving or derive instance Typeable (T a) Something to clearly signal the magic. The trouble is, as you mention, that instance decls usually have a context. I'd be quite happy to require a context in these derived instances too, so you have to write derive instance Typeable a => Typeable (T a) Then it looks more like a regular instance decl. Claus asks: | still, will non-variable parameters be permitted, and do we know | what that means? I was thinking of using exactly the same rules as now; type variables only. Simon

| Why not even simply | | instance Typeable (T a) | | In other words, derivable classes define default | implementations for all their methods.
But that has an existing meaning! It means "use the default methods for all methods of the class". Which is not the same as "derive all methods".
I was thinking about the proposed syntax in the "Derivable Type Classes" paper, which was just this. In classic Haskell, I can see that it is problematic whenever default methods are specified in terms of each other, like (==) and (/=) in Eq. I would then vote for
It'd have to be instance Typeable (T a) deriving
Perhaps it would be not much harder to allow instance Show MyChar deriving where showList = ... to partially override derived functions as well.
The trouble is, as you mention, that instance decls usually have a context. I'd be quite happy to require a context in these derived instances too, so you have to write derive instance Typeable a => Typeable (T a) Then it looks more like a regular instance decl.
Yes, even though it's more to write, I think it's cleaner if the context is specified. After all, the old "deriving" syntax within the "data" declaration will continue to be available for compatibility. Cheers, Andres
participants (2)
-
Andres Loeh
-
Simon Peyton-Jones