TDNR without new operators or syntax changes

Jeremy voldermort at
Sun May 22 15:01:07 UTC 2016

Bertram Felgenhauer-2 wrote
>> 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.

I was concerned about this, but not knowing anything about how
type-checking/inference is implemented, I wouldn't know if this is actually
a problem or not.

> 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.

Why special treatment for unambiguous names? They shouldn't be effected at
all by this.

View this message in context:
Sent from the Haskell - Glasgow-haskell-users mailing list archive at

More information about the Glasgow-haskell-users mailing list