TDNR without new operators or syntax changes

[Bertram Felgenhauer]

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