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.)
• Ryan Newton - I want it. I think the desire to import data schemas from other languages is another reason to care about this issue. For example, suppose we soon get a Haskell backend for the Google APIs client generator. We already have good technology for automagically creating JSON [de]serialization instances (Data.Aeson.TH), but the generated Haskell types have to either go in many modules or have very verbose field names. In particular, the client generator must use a hammer because it can't make the case-by-case nuanced decisions that a human programmer might. With TDNR the generator could create output more in line with all the other languages it supports.
• Gideon - very much want this. Many functions are easier to read in postfix (particularly record accessors), and this is an effective way to achieve it. The dot notation is good, because it follows naturally from module name resolution. It can also remove the clutter of redundant function qualifications.

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)
• Heinrich Apfelmus (I dislike:
  • The introduction of a second form of function application "argument.function" in addition to the ordinary "function argument" form.
  • The redundancy with type classes as mechanism to overload names. The proposal asserts that TDNR is not overloading, but it sure looks like overloading to me?
  • That the semantics are missing. Interaction with type inference, polymorphism, type classes, GADTs? I'd be surprised if the details would turn out to be much simpler than type classes.

    foo :: Ord k => [k] -> Char
    foo :: [[a]] -> Bool
    foo :: [Int] -> Int
    
    x :: [[Int]]
    x = [[1]]

    f :: ???
    f = x.foo

• Evan Laforge - The page says "Using qualified names works, but it is just sufficiently inconvenient that people don't use it much", with which I disagree. Since I use qualified names, it seems like I wouldn't be able to use TDNR without compromising. So it introduces an unpleasant tension. I don't think we should introduce major features that require a certain style. I would indeed love a shorter way to get record fields, but surely there is a simpler way? I am still hoping one of the "real record system" proposals is implemented, but this would really be the nail in the coffin for them.

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. [unattributed comment]

I think using . without spaces here is a natural follow on from its use with namespaces, so I don't have a problem with it. GaneshSittampalam 08:15, 24 November 2009 (UTC)

• This might be a really dumb question, but is there any reason TDNR needs to be tied to a new syntax for function application? It seems strange to me to have one syntax for left-to-right function application without TDNR, and then another for right-to-left application with it. I would much rather gain TDNR for the existing syntax, and then maybe introduce the dot operator as a separate option if people want it, which I don't. The reason I don't is that (.) as composition and ($) already work in one direction, which is the same direction (`foo . bar . baz $ bla` and `foo $ bar $ baz $ bla` are interchangeable), and while in a vacuum I might even prefer the opposite direction which (.)-as-application uses, it is much more important to be consistent. We have a vast body of functions already written and designed to be convenient with the existing direction: functions are generally of the form `f :: (what to do) -> (what to do it with) -> (result)`, which lends itself well to partial application/currying and chaining in the existing direction, but not the other one. (Object oriented languages which use the dot operator indeed also use the reverse order for their methods, with the object first and the action second.) Also, reading expressions where different parts work in different directions is very confusing. The one major exception which works in the other direction is monadic bind, (>>=), which I think was a (minor) mistake, and indeed I frequently end up using (=<<) instead. Anyway, executive summary: TDNR yea, dot operator nay. --Illissius 20:57, 7 August 2010 (UTC)

See Also

Syntax-Free Type Directed Name Resolution