On Mon, Sep 24, 2012 at 6:28 PM, Simon Peyton-Jones
| - Will it be possible to write e.g. deriving instance Typeable Eq?
Not at the moment; we've only been thinking about Typable for things whose kinds bottom out in *, not Constraint. There doesn't seem to be any fundamental obstacle -- but I can't yet see how it would be useful.
One aspect is that if you have SomeType :: Constraint -> * and want Typeable for SomeType c, which is *, you need Typeable c. But the particular application I had in mind is that you could implement OO-style casting-to-interfaces in a relatively clean way. class InterfaceCastable a where icast :: Typeable c => Proxy c -> a -> Maybe (Interface c) data Interface c = forall a. (c a, InterfaceCastable a) => Interface a instance InterfaceCastable (Interface c) where icast (Interface a) = icast a deriveInterfaceCastable :: Name -> Q [Dec] deriveInterfaceCastable could, for example, generate a Map TypeRep (a -> Any) based on the instances in scope for the named type, where the (a -> Any) is in reality a -> Interface c and the TypeRep is typeOf c, and then icast looks up the TypeRep for the constraint that it got, applies the function to its 'a' argument, and then unsafeCoerces the result back to Interface c. Which might be going into too much detail, but the point is that Typeable on constraints would be useful. (Workarounds are possible, the reason I ask whether this will be possible is whether it's worth working on them.)
| - How about deriving instance Typeable Typeable? (It seems Proxy Proxy | works, so maybe this would too.)
Ditto.
| - Does it make sense to have an instance for (~)?
Ditto.
| - Will instances be provided for the types in base and built-in to GHC?
Yes, that would make sense.
I should have said "for types which don't already have them and now could". But it seems you got my meaning.
| Automatically generate Typeable instances for every type constructor | that is declared. 'deriving Typeable' becomes a no-op.
Well, at the moment a type ONLY becomes an instance of a class if you ask for it to be so, so your proposal would be a change of principle. Sometimes *omitting* an instance declaration may be important (eg to prevent a type being serialisable). That said, I can't see when I'd want a type not to be Typeable. I suppose it could be a compiler option. I think the questions here are ones of software engineering rather than being technical.
Yes, it would be unorthodox. And it's definitely not applicable willy-nilly to other classes (where not having an instance can be important, as you say). But at the moment the only consequence I see of having to derive Typeable manually is hassle, with no upside. Typeable is increasingly a language feature rather than a library, with manual instances getting more-and-more discouraged, this would just take that train of thought further. Although, even if this were implemented, you would still need 'deriving Typeable' if you wanted to stay backwards compatible; and because it's a significant change to the language you would presumably have to hide it behind a language pragma, at which point instead of {-# LANGUAGE AutoDeriveTypeable #-} you might as well write 'deriving Typeable'; so maybe it wouldn't be so useful in practice.
Simon
-- Your ship was destroyed in a monadic eruption.