[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