[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.
More information about the Haskell-Cafe