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
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