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.
Regards, John 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, > ~wren > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
