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-changes-tp5835927p5836393.html Sent from the Haskell - Glasgow-haskell-users mailing list archive at Nabble.com. _______________________________________________ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users
