(sorry to mess up mail threading, but I couldn't properly reply to the message the way I'm using email right now--broken mail clients)

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.

In what kinds of ways? Sounds interesting.

[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 ...

This is the sort of thing I was thinking too. But I would probably want to extend that to classes and types. For instance module M (class Eq a=>C a (...), type A, instance C A, instance C a => C [a]) where ... If I am not mistaken, this would allow separation of the type namespace from the typeclass namespace, and would make it obvious whether the thing being exported is a type or a class. It could also potentially allow the context(s) for class and instance declarations to be more restrictive in the header or in imports than in the module body. The latter could perhaps allow resolution of overlapping instances at import time, by restricting the instances to the point of non-overlap. I'm not sure that the former would actually be useful. Hmmm.... speaking of overlapping instances... Would there be a practical way to add negation (of classes and possibly even types) to the context syntax? This would let you say instance (Integral a) => C (T a) where ... instance (not Integral a, Real a) => C (T a) where ... instance (not Num a) => C (T a) where ... .... It would also seem nice to be able to say instance (Integral a, not a Int) => C a where .... and instance C Int where ..... but this seems even more questionable.