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

[Josef Svenningsson]

Jon,

I'm sorry for my late reply.

I do sympathize with your general argument about introducing new small
functions in the library. However, I'd would like to once again argue
for the particular function intercalate. I don't think I was as clear
as I could have been in my original post.

My argument for intercalate builds on the fact that intersperse seems
to be the wrong abstraction. Recall that I supplied some evidence that
intersperse is only used together with concat:
http://www.google.com/codesearch?q=file%3A%5C.hs+intersperse&btnG=Search+Code

Except for pretty printing, intersperse always comes together with
concat. For me this suggests that intersperse is the wrong
abstraction. The right one is intercalate. Therefore, in the best of
worlds, intercalate should replace intersperse (or intersperse should
be moved to the pretty printing library, the seemingly only place it's
used). Of course that's not going to happen, at least not in the API.
But perhaps in the minds of Haskell programmers. We will hopefully
learn to use intercalate instead, and intersperse will slowly drift
out of our mental toolbox of library functions.

On 10/23/06, Jon Fairbairn <jon.fairbairn at cl.cam.ac.uk> wrote:
> If we don't give it a name, learning to read "concat
> . intersperse something" (which is more common than the
> formulation I gave above) means learning intersperse, concat
> and compose -- all of which are invaluable Haskell. But if
> we call it whateverify, there will still be programmes
> around that use concat with intersperse (I don't plan to go
> through all my old code and use the new name, and I doubt
> many would). Furthermore, for a seasoned Haskell programmer
> who wants to (for example) concatenate a list l with commas
> between the elements, what springs to mind is "concat
> (intersperse ", ") l" and it comes to mind so quickly that
> looking for a library function to do it would seem like an
> onerus additional task.  Of course, if that construction
> occurred several times in a programme, they might choose to
> call it "commas" or something for conciseness, but that sort
> of naming for brevity is a separate issue from putting
> something in a library.
>
This would be a valid argument, if it were for the fact that
intersperse really was invaluable, which it seems not to be.

> Certainly complicated enough constructions deserve library
> entries, and I admit I don't know where the break even point
> is, but I'm pretty sure it comes above two words and some
> punctuation -- unless it's something fundamental like
> composition.
>
This argument is orthogonal to why I want intercalate. I hope that
intercalate will replace intersperse, at least in my head, because it
seems to be the right abstraction. Apart from that I agree with what
you say.

I know that many people will argue that intersperse is somehow more
primitive or more natural than intercalate. As for being more
primitive, that's not true. Both functions are interdefinable. But I
agree that intersperse does feel more natural and simpler in a sense.
Yet, if it always requires some padding around it to make it work
(i.e. concat) then I would argue that it is *too* simple. Better use
the function which doesn't need the padding.

All the best,

Josef Svenningsson