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: http://haskell.1045720.n5.nabble.com/TDNR-without-new-operators-or-syntax-ch... Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com.