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

[Robert Dockins]

On Friday 10 November 2006 12:34, kahl at cas.mcmaster.ca wrote:
> Jón Fairbairn wrote:

[snip]

>  > The only conclusion I can really draw from this is that the
>  > argument that wins for me is still: intersperse got there
>  > first, it may not be ideal, but the grounds for adding
>  > another are too weak.

The Haskell standard libraries are not, and have never been, a minimal basis 
lacking redundancy.  Are you also opposed to the existence of

mapM f = sequence . map f

and other such useful goodies? I use mapM because it eliminates parens and 
reduces line length for a programming pattern I use a lot.  This increases 
redability of my code: win.  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.

I'm don't thing your criteria (which seems to be related to the ease with 
which the function is defined in terms of other, pre-existing functions) is a 
good discriminator for what should and what should not be in the standard 
libraries.

> The one I have been defining again and again is intercalate,
> mostly as:
>
> sepConcat :: [a] -> [[a]] -> [a]
>
> If it is not provided by the library, I will define it again,
> and many others will probably do the same,
> only perhaps with different names ...

In my view, this is the only point that really matters in this debate.

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.

We should codify this idea.  This function should be in the standard libs.  I 
personally don't much care what it's called.


> Wolfram

-- 
Rob Dockins

Talk softly and drive a Sherman tank.
Laugh hard, it's a long way to the bank.
       -- TMBG