Jeremy . wrote:
Yes, that it indeed was I meant. AntC seems to be replying to a much more complicated/invasive proposal than what I had intended, apologies if I wasn't clear. (I see in retrospect that I may have misunderstood the original TDNR proposal, understandably leading to confusion.)
Your client broke the thread (it didn't add any References or In-Reply-To headers, and in my case I received the haskell-cafe copy first, so matching by Subject didn't work either). In any case this paragraph wouldn't make sense to anyone on the haskell-cafe or libraries mailing lists.
1. If the compiler encounters a term f a, and there is more than one definition for f in scope (after following all of the usual rules for qualified imports);
2. And exactly one of these definitions matches the type of a (or the expected type of f if given);
3. Then this is the definition to use.
I now find that Anthony's concerns are justified. The question is, what exactly does the type matching in step 2 involve? If it is a recursive call to the type-checker then you'll have a huge performance problem. If, on the other hand, you only take into account what is known about the type of a at a given time, then you need special treatment for unambiguous names or even trivial programs will fail to type-check, just as Anthony said. There's another concern: will type checking still be predictable? How do you explain type checking errors that arise from ambiguity to the user?
That is all, although point 2 could be extended to consider the return type of f or other arguments as well. Even with the extension on, it would have no effect on programs which compile without it.
Right, so what is special about the first argument? Do you have any use case in mind that goes beyond record field selectors? Cheers, Bertram