Names for small functions: just say no... Re: Data.List.join
robdockins at fastmail.fm
Fri Nov 10 12:51:35 EST 2006
On Friday 10 November 2006 12:34, kahl at cas.mcmaster.ca wrote:
> Jón Fairbairn wrote:
> > 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
> 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.
Talk softly and drive a Sherman tank.
Laugh hard, it's a long way to the bank.
More information about the Libraries