On Nov 12, 2010, at 5:43 AM, Richard O'Keefe wrote:
A saucepan whose handle keeps falling off is defective,
I do not see TDNR as unambiguously defective as a loose saucepan handle.
The amount of time spent maintaining a program is much higher than the amount of time spent creating it initially. That means that if you have a tradeoff between ease of writing and the other virtues of a language, ease of writing *matters* less.
Like you, I think that a tradeoff between readability and writability should be made in favour of readability. Unlike you, I am not convinced that TDNR trades readability for writability.
Consider the vexed question of repeating all or part of the record name in the field name. Yes, this *is* a burden on the person writing it. But it is a **help** to the person reading it. The same applies to using module prefixes (possibly abbreviated ones).
Not if the extra information is redundant. Then qualification may even impair readability by introducing unnecessary clutter. I don't think that TDNR threatens readability more than type classes already do. Not only is "Buffalo buffalo Baffalo buffalo buffalo buffalo Buffalo buffalo" a grammatically valid sentence in the English language, also `fmap fmap fmap fmap fmap fmap fmap fmap` is a type correct expression in the Haskell programming language. It can already be hard today to distinguish occurrences of overloaded functions. TDNR does not add much to this, I think. One difference is that there is a unifying type with a type class constraint for all implementations of functions with the same name when using type classes but not when using TDNR. Does this make code that is using TDNR less readable than code that is using type classes? As others have pointed out, type classes are insufficient for overloading record labels because they do not cover record updates. How can we add a special kind of overloading for record labels that also works for updates? Maybe like this: rename :: ((name :: String) @ a) => a -> a rename newName someRecord = someRecord { name = newName } This probably falls under the category of improved record systems. How difficult would it be to implement this? Can it be implemented by desugaring without substantial extensions to the type system? Sebastian