Names for small functions: just say no... Re: Data.List.join

[Jon Fairbairn]

I simply don't have the stamina to follow up to all the
objections to my messages. I'm posting this here in the
thread because it's a convenient point, not because Robert's
message troubles me particularly.

Evidently I'm not getting my point across, so I'll give one
more try and then call it a day (for ten years or so, then I
can look again and see if the wind has changed).

1. I don't want to remove any extant library functions --
   these have already been subsumed into the collective
   consciousness.

2. I'm not opposed to intercalate in particular, it's just
   an instance of what I perceive to be a growing problem.

3. I'm not going to be strongly opposed to any particular
   suggested small function -- each usually has the merit of
   reducing the number of tokens in the code, which with all
   else being equal would be a good thing. All else is not
   equal, though. I was going to post something more in the
   thread on adding on, in that ultimately “<comparison>
   `on` fst” is more readable than “equating”, “comparing”
   and friends, simply because of the quantity of names. But
   even of those I cannot get really excited in my
   denouncement.

I don't know for certain about anyone else, but I for one
have a limited capacity for learning arbitrary names.  I'm
pretty sure there's a limit for most people, but for some
the limit is so large that learning all the names in all the
Haskell libraries that there will be in the future won't be
a problem. Such folk aren't going to be inconvenienced in
the long run, but for feeble minded people such as myself,
the application of a brake to the proliferation of names
would be an important gain.

To draw a parallel, for most of my life I've been
intermittently trying to learn Chinese characters. There are
so many, and although there's a degree of compositionality
from radicals to whole characters, a great deal of the
relationship between any complex character and its meaning
is arbitrary. Consequently I've yet to learn enough that I
can read a single sentence in Chinese. Six years ago, I had
a Russian lodger and thought it would be fun to learn a bit
of Russian.  There's only a few more characters in Russian
than English, so I learnt them all in a couple of days (not
the order, though: that's arbitrary). After that, I found
that Russian words are often composed of prefixes that
modify the meaning of smaller words¹. Because of this, even
without trying at all hard I can already read quite a bit of
Russian.

The difference is that with Chinese characters there's a
whole lot of arbitrary symbols to learn before you can get
anywhere, while with Russian there seems to be fewer
arbitrary symbols at each level. (This isn't just me, by the
way: Chinese characters are a significant obstacle to
literacy in China -- it's even possible that was originally
deliberate -- so they use pinyin) What I'm advocating is
that when deciding whether to put something into a library
we make sure that it's worth the extra effort to the reader,
so that reading Haskell doesn't become as hard as reading
Chinese -- only as hard as Russian ;-).

To twist Gauss's snippy remark to Wilson into a rule, what I
want is no new notations without new notions. If you can
name something without controversy so that the ordinary
English (or mathematical) reading both tells the reader
immediately what the function does and is obvious to the
writer looking for it (the latter is the lesser), then it
can go in a library. Otherwise we have to consider: is there
a more powerful function that does the job? is it possible
to define the same function at a higher type? is the name
going to be more useful at a different meaning? is the named
version /really/ more readable than the expression it stands
for? And it's not always going to be possible to answer
those questions without considerable work.

Particularly the last case: it's quite hard, especially for
a beginning (or intermediate) programmer, to escape the idea
that by naming a short bit of code one has made it simpler.
Part of the trouble is that, having had to think about the
thing long enough to want to name it, the name becomes (for
that programmer) a shorhand for the entire process of
discovering the combination. Ten years later, the discovery
doesn't seem so radical, reading the short bit of code is
straightforward and remembering what the name means has
become difficult.

On 2006-11-10 at 12:51EST Robert Dockins wrote:
> The Haskell standard libraries are not, and have never
> been, a minimal basis lacking redundancy.

I'm not sure how you got the idea that that's what I want.
There are several reasons that can make naming something
short worthwhile. Take “sum”. It's code is short, but there
are decisions to be made (foldl or foldr &c) that mean that
the name abstracts something useful away from the code.  The
things I've been objecting to are pretty much the only way
of writing something in terms of predefined functions.

>  Are you also opposed to the existence of
> 
> mapM f = sequence . map f

That's an interesting case.  I'm not, because of point (1)
above, but I reserve the right to whine about it.  Having a
naming convention is better than having completely arbitrary
names, but the fact that a convention was needed should
raise suspicion.  Given that we had concatMap already,
sequenceMap would have been a more easily interpreted name
-- and then some people would wonder, why bother with the
name?  It took me a while to realise that mapM isn't some
form of [f]map, and longer still to notice that fmap for
Monads is inexplicably called liftM.

> and other such useful goodies? I use mapM because it
> eliminates parens

You save one pair. 

> and reduces line length

by a small constant

> for a programming pattern I use a
> lot.  This increases redability of my code: win.

Yes, but there's a reduction in readability too, though it's
harder to notice once you've learned the name mapM, and so
long as the number of names like that in libraries is small
the loss of readability in this way is negligible. But if we
go on adding such names, it will become a real problem.

> Codifying this pattern by placing it in the standard
> libraries means that most people use the same name for the
> same concept, increasing overall readability: win.

On the other hand, if there were no names for it and people
wrote the same thing in each case, it would be just as
readable. (Do I need to repeat that point (1) makes this
specific case moot?).

We need names for medium to large concepts, not for really
small ones.


> Programmers find this concept useful and they name it.
> This has been done independently by multiple people
> persuing diverse ends.  The fact that this function isn't
> in the standard lib means that programmers name it
> different things and, in the long run, this harms
> readability across Haskell code.

Well, for the specific case of intercalate, the data Joseph
presented doesn't support that -- there were lots of
instances of the code written out, but only a few where this
was the body of a definition, and some of the definitions
were for a specific separator.

Finding a concept useful and naming it is something that
programmers do, but it's far from clear to me that it's
always what they should do. I can't present a real life
case, but it seems to me that there will be times when it
obscures what's going on.  For example suppose “weeble
. sort” occurs often and is given the name “foo” and that
“reverse . whiffle” has similarly been named “bar”.  Now, a
programmer who writes “foo . bar” might be quite happy that
this does the right thing and fail to notice that “weeble
. sort . reverse . whiffle” simplifies to “weeble . sort
. whiffle” (given appropriate conditions). This is
particularly likely when a library function has been found
without looking at the code.

Nor do I think that programmers naming things differently is
/necessarily/ a loss, either. Sometimes the name says
something about the intentional meaning that use of a name
from a library would not. Finally, we have to question how
far one has to search to find the definition of a name.
There are (a) names that one knows already (but there is a
limit to how many of these there can be), (b) names defined
in the module one is currently reading, and (c) unfamiliar
names defined elsewhere that one has to look up.  That is, I
think, a list in order of difficulty, and the more names
there are in libraries, the more times what was hoped to be
an (a) becomes a (c).

  Jón

[1] eg опасность means danger, безопасность is
without+danger = safety, небезопасность is
not-without-danger = insecurity. For some reason I find this
amusing.

-- 
Jón Fairbairn                              Jon.Fairbairn at cl.cam.ac.uk