Re: Overlapping, undecidable, incoherent -- or worse?

I think you should read the GHC manual (assuming it is up to date and undecidable instances means what it says it does, the difference is... Without undecidable instances at least one type in the instance must not be a type variable. With undecidable instances you can have a default-instance (all type variables) or a class synonym (one instance - all type variables) Thats it... Neither GHC nor Hugs pay any attention to the dependancies when choosing which instance to use. The dependancies are only considered after the decision has been irrevocably made. If the dependancies don't hold, the only option the compiler has is to bail out with a compile time error. Keean.

On Thu, May 20, 2004 at 09:25:20PM +0100, MR K P SCHUPKE wrote:
Thats it... Neither GHC nor Hugs pay any attention to the dependancies when choosing which instance to use. The dependancies are only considered after the decision has been irrevocably made. If the dependancies don't hold, the only option the compiler has is to bail out with a compile time error.
Let's recap. You observed that taking dependencies into account leads to "further problems of the compiler possible not terminating". I didn't dispute that ghc and hugs _do not_ take such dependencies into account, I pointed out that the type system _may already_ not terminate (and not just hypothetically, but for the option I was using and the class of instance in my original example, with or without the duplicate heads). So from a theoretical pov I didn't, and still don't, see how this would be 'worse'. That this is clearly not what ghc does or is likely in the near future to do probably puts this in the category of language list fodder, though.
participants (2)
-
Alex Ferguson
-
MR K P SCHUPKE