It's certainly true that, with the current setup, a monomorphic instance will look like
instance Typeable Foo where
typeRep# = \_ -> (...something...) :: TypeRep
and the optimiser will float the (...something...) to top level. But this is an optimisation, not true by construction. For example, a non-top-level instance might look like
instance (Typeable a, Typeable b) => Typeable (a b) where
typeRep# = \_ -> mkAppTy (typeRep# (undefined::Proxy a))
(typeRep# (undefined :: Proxy b))
And that in turn will become
$dfTyApp = /\a b. \(d1::Typeable a) (d2::Typeable b).
\_ -> mkAppTy (d1 a) (d2 b)
(I'm missing out some newtypes etc.) Now, will the (d1 a) and (d2 b) be floated outside the \_? Not so certain. It depends on the let-floater.
The good thing about the Tagged stuff is that there is no lambda in the first place, so the issue doesn't arise.
It's ok if the programming interface is less easy to use; Data.Typeable.typeOf is already a function, not a method. The method is called typeRep#, and is internal.
So I think you can go ahead and improve the design. But it's clearly a library-committee decision; I'll just do what you say.
Simon
From: Libraries [mailto:libraries-bounces@haskell.org] On Behalf Of Dan Doel
Sent: 10 March 2014 18:02
To: Roman Cheplyaka
Cc: Haskell Libraries
Subject: Re: Data.Dynamic: Any vs existential
On Mon, Mar 10, 2014 at 6:35 AM, Roman Cheplyaka