| But your following comment is even more important: "of course, this instance
| overlaps with all other instances." Now, ordinarily, overlapping instances are
| resolved so that a more specific instance is always chosen in preference to a more
| general one. If I typed in `wrap [1, 2, 3]', which instance of `fmap' would you
| expect to be used? By the general overlapping instance rule, we'd expect the List
| instance of Functor to be used. However, what hugs previously did is chose the
| `Monad m => Functor m' instance, thus silently overriding the overlapping mechanism
| by chosing always the more general instance.
|
| Is this what you meant it to do? We decided that hugs shouldn't silently make this
| decision for you.
Well, I see the problem. Thanks for pointing this out. BUT, as we know
I doesn't matter in this particular case which instance Hugs chooses as
both are the same! So, in giving a completely `generic' instance like
> instance (Monad m) => Functor m where
> fmap f m = m >>= return . f
I kind of tell the compiler that overlapping instances are guarenteed
to be identical. This is, of course, a proof obligation for the
programmer.
| Looking at the signature of wrap again, by omitting `Functor' from the context, you
| are telling hugs to commit to a particular instance for `Functor'. Previously, it
| chose the more general instance. Now, it recognizes that it's too early to commit
| to a choice, because there are also more specific instances of `Functor' around,
| and it's too early to rule them out.
|
| So, the solution is simply to put `Functor m' in the signature for `wrap'.
Oh no! If I have to this then the `generic' instance is completely
useless! Do you agree? So please provide the old behaviour, as well.
Otherwise, there is no point in allowing `generic' instances.
| > I got bitten by something similar when upgrading. I've not got access to
| > a Hugs98 interpreter right now, but IIRC there's a new option +m (?) you
| > need to set to get the old behaviour back. There's a section in the
| > hugs manual which explains this flag.
|
| Hmm... most unfortunate! This is a bug. The reason you got the old
| behavior back is because the multi-instance resolution function doesn't
| have the overlapping instance change (talked about in my last note) applied
| to it.
Oh no, again. This is a wonderful bug ;-).
Cheers, Ralf
