On Wed, 09 Aug 2000 00:20:34 +0200, Volker Stolz
<[EMAIL PROTECTED]> wrote:
> *sigh*. I wonder why comments like this in Dynamic.lhs
>
> "Provided the implementor of other @Typeable@ instances
> takes care of making all the @TyCon@s CAFs (toplevel constants),
> this will work."
>
> ...donīt get written in bold, bright and friendly letters across the
> (HTML-)documentation...
> Of course afterwards it seems straight forward to skim *all* of the
> library source-file,
> but I suggest putting this note near the *top* of Dynamic.lhs ;)
>
> If you donīt create a function like
>
> > instance Typeable Msg where
> > typeOf _ = mkAppTy msgTc []
> > msgTc :: TyCon
> > msgTc = mkTyCon "Msg"
>
> but simply use
>
> > instance Typeable Msg where
> > typeOf _ = mkAppTy (mkTyCon "Msg") []
>
> you can search for hours why "fromDynamic" wonīt work.
The same thing happened to me when I tried to test Dynamic.lhs distributed
with Hugs98. The library module seems to have been imported from the GHC
distribution, so it worked only after moving the sub-expressions to the
top level.
The real source of the trouble is the way of assigning a unique number
to each type constructor representation. These numbers are then used
to identify type constructor representations like this:
-- type constructors are
data TyCon = TyCon Int String
instance Eq TyCon where
(TyCon t1 _) == (TyCon t2 _) = t1 == t2
Dynamic.lhs distributed with GHC and Hugs98 utilizes unsafePerformIO
in generating unique numbers, but it also assumes that the representation
of each type constructor is generated at most once.
This property is ensured by a particular optimization phase of GHC.
A less reliable but more portable one is like this:
instance Eq TyCon where
(TyCon _ s1) == (TyCon _ s2) = s1 == s2
I used to use this variation for a while, in order to implement association
arrays from strings to heterogenious objects.
----
Yoshihiko Ichikawa
Department of Information Sciences, Ochanomizu University
Phone: +81-3-5978-5708; Fax: +81-3-5978-5705
E-mail: [EMAIL PROTECTED]
