TypeDirectedNameResolution

Type directed name resolution

This publicly editable page is a place to summarise comments on the Haskell Prime proposal for Type Directed Name Resolution (TDNR).

• The TDNR proposal

Straw poll

It's hard to gauge how much people like proposals like this, so let's try the experiment of collecting votes here:

Names of people who would positively like to see TDNR happen (say briefly why)

• Simon PJ (I wrote the proposal)
• Daniel Fischer (I think it would be an improvement to the language. I have not much missed it yet, so I don't feel strongly about it, though.)
• Levi Greenspan (The current module-scoped record selectors represent a major burden when defining many records with similar selectors, for example the "channel" property in Bayeux protocol messages. See "How to implement this? ..." for details. Currently only type classes can be used as a workaround but only with lots of boilerplate code consisting of instance definitions. TDNR would be of great help.)

Names of people who think that on balance it's a bad idea

• Ganesh Sittampalam (see http://thread.gmane.org/gmane.comp.lang.haskell.cafe/61723 ; I think that having constraints you can't quantify over is a bad idea. However if that is fixable I'd be generally in favour.)
• Malcolm Wallace. (I see the attraction of the idea, but find the use of '.' highly confusing. If there are spaces around the dot, it is normal functional composition, if no spaces, then it is almost like composition in the opposite direction. Also, there seem to be lots of special cases based on what is easier to implement - the design does not seem sufficiently orthogonal and clear-cut. There is a new form of lightweight overloading hiding here, but it is struggling to fight its way out of a tangle of syntactic issues.)
• Luke Palmer. (I don't like the idea that I could break someone's code that doesn't have anything to do with mine by changing one of my types -- that is, if they are using an overloaded function with the same name as mine. Also I echo Ganesh's concern)

Other comments

• A lot of people have commented that using . for this as well as composition and qualification is going to start getting confusing. One alternative suggestion was -> but this would conflict with case branches and lambda syntax. Similar things like ~> or --> could work too, but look a little uglier.

However, I think a little ugly is preferable to confusing or conflicting with syntax. I think using '.' won't be too confusing (we all separate the composition operator from the functions by a space anyway, don't we?), so I'd go with that. But rather than letting it die over '.'-ambiguity, I'd choose a different notation (would a#f be an option?).Daniel.is.fischer 21:06, 17 November 2009 (UTC)

No, I often use composition now without surrounding spaces.