On Sat, Jun 01, 2002 at 07:56:39PM +0100, Alastair Reid wrote:

Your Typeable instance looks like this:

...

instance Typeable FootnoteData where typeOf _ = mkAppTy (mkTyCon "FootnoteData") [typeOf ("Foo" :: String), typeOf (7 :: Int)]

This should be written:

...

instance Typeable FootnoteData where typeOf _ = mkAppTy fdtc [typeOf ("Foo" :: String), typeOf (7 :: Int)]

fdtc = mkTyCon "FootnoteData"

That is, the TyCon definition has to be a CAF (i.e., a top level definition with no arguments). The reason is somewhat grubby but comes down to 'things go much faster if you do this').

I see, thanks. I'll try to update the documentation with this note.

While we're at it, I'd like to repeat my request that the word 'unsafe' be made part of the classname Typeable or the method name typeOf. The reason is that a badly written Typeable definition can break typesafety. Here's a superficially plausible but broken instance for IO which demonstrates it

...

instance Typeable (IO a) where typeOf _ = mkAppTy iotc []

iotc = mkTyCon "IO"

With this definition

typeOf (return 1 :: IO Int) == typeOf (return () :: IO ())

and so you can coerce back and forth between these types using from/toDynamic.

Ahem, this is what I actually did to get my Dynamic types working in the first place (oops) :). mkAppTy was being given an empty list of TypeReps, since I was confused about how to generate those TypeReps. It would be much neater if you could do something like instance Typeable Foo where typeOf _ = mkAppTy constructor [Char, Char, Int] This is what I expected the Dynamic module interface would look like, since when do you "typeOf 'a'" in GHCI, it does reply with "Char". I guess a possible workaround would be something like charT = typeOf ('a' :: Char) intT = typeOf (69 :: Int) instance Typeable Foo where typeOf _ = mkAppTy constructor [charT, charT, intT] which is what I'm doing right now. Maybe these type definitions can go into the Dynamic module itself? -- #ozone/algorithm - b.sc (comp. sci+psych)

just as a note, the new version of DrIFT (which i now maintain) has the ability to derive 'Typeable',

Very cool. (Though I'd still like to see Typeable being moved into compilers.)

I sort of fudged the Typeable derivation rule, if someone wanted to robustify it, i would gladly accept patches.

You should add a few test cases involving functions to your instance - dashed tricky to get those ones working. As a challenge, here's a typical state-passing monad datatype: newtype M s a = M (s -> (s,a))

I dont think that 'unsafe' need be added to Typeable since hopefully people will never be creating instances themselves, with the instances hidden behind DrIFT and/or 'deriving' clauses then they can be assured of being correct (well... as correct as anything is :)) .

Sadly, most people aren't using DriFT for that and it seems likely that people will continue writing them by hand and will continue to get them wrong.

Typeable itself is not inherently unsafe, it is broken implementations of it which are.

The same situation applies with the use of unsafePerformIO. There's nothing wrong with using unsafePerformIO (well, it is semantically a little ugly but apart from that...) - the problem is people misusing it. The idea of putting the word 'unsafe' in the identifiers is: 1) To try to get people to wake up and start thinking hard about what they're doing when they write these instances (or, if they used DriFT to generate them, to make them wake up if they start modifying them by hand). 2) To make it easy to home in on problematic pieces of the system when it starts disobeying Haskell rules. Typesafety broken? grep for 'unsafe'. Referential transparency broken? grep for 'unsafe'. Received puzzling bug report? grep for 'unsafe'. -- Alastair