I know you're all probably pretty tired of hearing from me, but I have a style question. Let's say I'm defining a hashmap. I have a module HashMap which defines a class Hashable a where hash :: a -> Int or something like that. I have a common datastructure called a Foo which I want to be able to hash. Foo and a bunch of accompanying functions are defined in module Foo. Where should I put the instance Hashable Foo? (1) In Foo.hs pros : seems somewhat appropriate since it's basically defining a function on Foo and if I don't export the constructors for Foo, this is the only place it can go cons : means i have to import HashMap into Foo even though I'm not actually using a HashMap. Sure I can only import the part I need. (2) In HashMap.hs pros : when you import HashMap you get all necessary instances cons : Foo is application specific, HashMap is not; reduces reusability <-- I don't like option (2) (3) In Instances.hs -- i.e., create a new file for instances pros : modular cons : what if FOo doesn't export constructors? requires importing lots of files which often slows down compilation since a change to one things means *everything* has to recompile (4) something I haven't thought of I know edison tends to follow (3); in general I follow (1), but sometimes I run in to problems of mutually dependant modules this way. How do people resolve this problem? - Hal -- Hal Daume III "Computer science is no more about computers | hdaume@isi.edu than astronomy is about telescopes." -Dijkstra | www.isi.edu/~hdaume