Mark P Jones wrote:
>
> | I eagerly awaited the Sep1999 hugs release because I hoped the MPTC
> | dependencies feature would allow a certain capability I was looking
> | for. I was disappointed. I think this is all best explained with an
> | example:
> |
> | > class Zippable a b | a -> b, b -> a where
> | > zip' :: a -> [b]
> | >
> | > instance Zippable () () where ...
> | > instance (Zippable b c) => Zippable ([a],b) (a,c) where ...
> | >
> | > test = zip' ("abcd",())
> |
> | Hugs-Sep1999 gets the following error message:
> |
> | > ERROR "Zippable.hs" (line 14): Unresolved top-level overloading
> | > *** Binding : test
> | > *** Outstanding context : Zippable () b
>
> Try adding a dummy argument to test (so the monomorphism restriction
> doesn't kick in), and then look at the type that Hugs infers:
>
> > test () = zip' ("abcd", ())
>
> Main> :info test
> test :: Zippable ([Char], ()) (Char,a) => () -> [(Char,a)]
>
> Now you can see that Hugs has done some improvement (i.e., it has
> determined that the second parameter must be a type of the form
> (Char, a)), but hasn't gone all the way that you expected in
> determining that a = (). In the presence of overlapping instances,
> such a conclusion would not be valid.
True, but I haven't enabled overlapping instances. If supporting
overlapping instances means the type system will be less "intelligent",
even when they are absent, then I would vote against supporting them at
all (if I had a vote :). Perhaps we could declare per class whether
overlapping instances should be allowed?
Am I correct in assuming that if hugs could determine that a = () (as
discussed above), then my original test function would no longer suffer
from the monomorphism restriction?
>
> Curiously, however, when you type in test() (or similar variant) at
> the evaluator prompt, it displays a message that suggests a different
> constraint here, namely Zippable () a, which really looks like it
> could have been improved by using the first instance. What's happened
> is that, in a desperate attempt to try and resolve overloading, Hugs
> has resorted to doing some context reduction, and thereby reduced
> the constraint to Zippable () a. It's easy enough to add the extra
> lines that are needed to persuade Hugs to try for a further improvement,
> and in this particular case, it then works as you expect. A total of
> four lines are required; look for a patch soon.
How soon? I'm dying to see it!
>
> The fact that this would get your program to work, however, really is
> just a coincidence. There are technical issues to be resolved
> here in understanding how we can get Hugs to make more use of the
> information on the left of the => symbol in an instance declaration,
> without requiring support for overlapping instances to be turned off.
Do we even know that it works in theory? I get the feeling that
overlapping instances are sort of incompatible with using that info, at
least the way I would like it to be used, because another instance could
give a whole different set of rules.
>
> | P.S. yes, I did remember to use -98 to enable the hugs extensions
>
> It wouldn't have accepted the functional dependency syntax if you
> hadn't!
Right, I knew that. :)
>
> All the best,
> Mark
