| > * General Type Directed Name Resolution (GTDNR): | > For every function application "f x" in the program where "f" is a | > name, "f" is resolved based on the type of the argument "x". | > ... | You suggest that GTDNR might not be a good idea, well why not? One | reason is that it can potentially lead to a whole lot of guessing, | slowing the compiler down dramatically and maybe even so much guessing | that there are multiple whole-program resolutions (oh noes!). So how can | we control that combinatorial exploration of alternatives? One way would | be to restrict the places where we allow guessing. There's still | potential room for combinatorial explosions but they're greatly reduced, | both because we reduce the number of variables in the problem (so the | combinatorics are smaller), and because we (generally) will have a good | deal of non-variable context to anchor the disambiguation process and | hopefully resolve the variables easily. Yes. I'm confident that GTDNR is not viable. The TDNR proposal is carefully constrained to give a uni-directional "information flow" from the "record field" to select the function. I don't think that the vastly more general idea you propose is going to work when combined with ordinary HM type inference, type classes, type functions, etc etc. Of course, I could be wrong. Simon