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

I don't think you get it... naming does not help, the problem is the compiler cannot distinguish between the instances. The alternative to the current situation is to take into account the dependancies of instances when selecting. The problem here is that the compiler may select an instance, evaluate its dependencies, only to discover somewhere further on that the dependencies cannot be met. At this point it has to backtrack (reverse its previous decisions) and try another instance. This effectively means implementing a Prolog style solver in the compiler - which leads to the further problems of the compiler possible not terminating (ie taking forever to not compile something)... Keean.

On Thu, May 20, 2004 at 05:58:53PM +0100, MR K P SCHUPKE wrote:
The alternative to the current situation is to take into account the dependancies of instances when selecting. The problem here is that the compiler may select an instance, evaluate its dependencies, only to discover somewhere further on that the dependencies cannot be met. At this point it has to backtrack (reverse its previous decisions) and try another instance. This effectively means implementing a Prolog style solver in the compiler - which leads to the further problems of the compiler possible not terminating (ie taking forever to not compile something)...
Which is the case as soon as you use the -fallow-undecidable-instances flag in any event. My suggestion might make things worse pragmatically, but I don't see it can be any moreso theorically. You may claim that it's not an attractive change, or doesn't help in some more general case than the one I asked about; but I don't see how you can possibly maintain it immediately wrecks the type system, or that it doesn't resolve the problem in this case, which is not so much that finding a valid instance is difficult, but that there are _two_ possible such, and no way at the language level to say which is desired.
participants (2)
-
Alex Ferguson
-
MR K P SCHUPKE