[Haskell-cafe] Type Directed Name Resolution

Sebastian Fischer fischer at nii.ac.jp
Fri Nov 12 00:06:19 EST 2010


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


More information about the Haskell-Cafe mailing list