Jonathan King wrote:
> > transformListElems :: (elem -> elem') -> List elem -> List elem'
> > transformListElems transform Nil = Nil
> > transformListElems transform (Cons elem elemRest) =
> > Cons (transform elem) (transformListElems transform elemRest)
>
> Well, the second version does more than just use descriptive variable
> names (and some not very descriptive, for that matter). It also spells
> out constructors, has an especially long-winded function name, and uses
> one name for both a type variable and an argument (and a "primed" version
> for a second type variable).
Heh. :) I agree that using different constructor names is probably going
overboard, but when I look at industrial-strength C++ code it is not at all
uncommon to see such long-winded, redundant definitions, although they
usually aren't so polymorphic.
> You point out that short variable names keep code segments short, but my
> take on the why Haskell seems to "prefer" short names in many situations
> is that they are easier to think of as being *generic*. (Intuitively,
> when you make a concept something more specific, it tends to get a longer
> name.)
That thought occurred to me too, but I had to reject it. Variable names can
be chosen in at least two ways: according to their domain (e.g., "File," or
less concretely, "f"), or according to the role they play in the definition
in question (e.g., "elem" or "kont"). If the variable is completely
polymorphic (or generalized), then its domain is essentially unrestricted,
but it still has a particular role to play.
Maybe a better motivation/explanation is simply that the descriptiveness of
a variable name is typically inversely proportional to the size of its
scope, where, realistically, the measure of scope size should involve both
textual length and expression size.
> > Of course, for more involved definitions, it is better to use
> > descriptive names.
>
> Well, for more specific definitions, anyway. If I've got the style right.
For more specific definitions too. But if, say, you reimplemented a function
with a more efficient algorithm, you might be persuaded to use more
descriptive names, at least internally. But maybe you're right and
"specific" is more specific than "involved." :)
--FC
