instance declarations

[Mark P Jones]

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