Hi David, | 1. Why can't they be hidden in module imports/exports? Is this an | implementation issue (I guess I could see it as a problem with the | dictionary-passing approach...)? It seems kind of bad that instances are | not allowed to overlap, but can't be hidden. There's no solid technical reason for this, but Haskell doesn't allow it at the moment because there isn't an easy way to name an instance declaration. And if you can't name it, then you can't put it in an import/export list. Also, I don't think people thought it was worth the hassle of introducing a syntax for naming instances when the only thing it could be used for was controlling imports and exports. Recently, however, there has been some interest in using named instance declarations in other ways, so perhaps we will see features like this creeping into future versions of the language. [Of course, there is a way of naming instance declarations with the current Haskell syntax, although it is a little verbose, and would require more work on the implementers part than simple matching of strings. The syntax I'm thinking of would look something like the following: module M(C(..), instance C Int, instance C a => C [a]) where ... Other variations, either more or less verbose, are possible. Personally, I think it would be nice to be able to document class instances explicitly like this as part of module interfaces.] | 2. Why can't you simultaneously declare a type to be an instance of | multiple classes? i.e., why can't you write the following? | | class C1 t where | a::t->t | class C1 t => C2 t where | b::t->t | | instance C1 t, C2 t where | a=... | b=... Again, there's no problem with this in theory, but it has the potential to be messy in practice. What would the syntax for this look like in the general case? What if you wanted to include contexts on the instance declarations? A nicely worked out proposal that answers questions like these in the general case, without seeming ad hoc or arbitrary, might attract some interest from implementers. As things stand, however, I'm guessing that most people don't find they need this feature often enough to justify extra complexity in the language definition. All the best, Mark