[Haskell-cafe] Status of TypeDirectedNameResolution proposal?

wren ng thornton wren at freegeek.org
Fri Nov 20 02:13:15 EST 2009

Twan van Laarhoven wrote:
> My point is that desugaring "x.f" to "(f x)" and treating some instances 
> of "(f x)" as "(ModuleToGuess.f x)" are two separate things. In the 
> current proposal these two are combined, but I see no reason to do so.
> To be a bit more concrete, I would propose:
>   * 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".
> Note that I am not saying that this is necessarily a good idea, it is 
> just a possible alternative to the current TDNR proposal.

I'm not a big fan of any of the TDNR proposals I've seen (I think we 
still haven't found the right way to do it without it being just a 
hack), but I can give one good reason for why these two parts of the 
proposal are grouped together.

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.

Live well,

More information about the Haskell-Cafe mailing list