[Haskell-cafe] Status of TypeDirectedNameResolution proposal?
John A. De Goes
john at n-brain.net
Fri Nov 20 09:17:48 EST 2009
GTDNR is what I really want anyway... whether or not it's possible. :-)
At any given time, importing everything unqualified from every module used by a typical hs leads only to a handful of ambiguities. While the general case might be "intractable", real-world cases might be trivial.
On Nov 19, 2009, at 11:13 PM, wren ng thornton wrote:
> 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,
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe