Changes to Typeable

[Gábor Lehel]

On Mon, Sep 24, 2012 at 6:28 PM, Simon Peyton-Jones
<simonpj at microsoft.com> wrote:
> |  - 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.