[Haskell-beginners] Re: Integer factorization

Francesco Bochicchio bieffe62 at gmail.com
Sat Mar 14 07:21:22 EDT 2009

2009/3/13 Heinrich Apfelmus <apfelmus at quantentunnel.de>

> Francesco Bochicchio wrote:
> > Heinrich Apfelmus wrote:
> >>
> >> Stylistically, one usually uses shorter variable names in Haskell.
> >
> > <beginner rant>
>  ...
> > </beginner rant>
> >
> > Rant apart, I notice that in my own excercises I tend to shorten names,
> so
> > maybe there is a reason for that.
> > Nevertheless readability tends to be a big issue in languages used in IT
> > industry, and my feeling is that haskell
> > tends to err on the laconic side of the balance.
> The goal is of course to make code readable, that's why I recommend
> short names. :D
> Abstraction is the one driving force for very short names. For example,
> take the definition of  foldr
>   foldr f z []     = z
>   foldr f z (x:xs) = f x (foldr f z xs)
> Since this function is polymorphic, so f , z  and the  xs  can be
> anything, using more "descriptive" variable names is simply not
> possible; the key point of fold is its generality.

Ok but one could still hint at their structure or purpose:

foldr function value (x:xs) =  function x ( foldr function value xs )

I believe this would give a little more information to the casual reader.

> A second, and my main reason for short names, or rather against long
> names, is that names should be to the point. None of the names
>   newPrimes
>   topPrime
>   doFactors
>   doFilter
> accurately describe the object they represent. The primes are not "new",
> the prime is not "on top". The "do" is a prefix does not carry a meaning
> either, it just conveys that  doFactors  has something to do with
> factors . This is best expressed by making  doFactors  a local
> definition in the where-block of  factors .

I agree that well-documented shared name conventions are better than
 (x:xs)  is one example of such convention, although I tend to adopt slight
like (n:nums) for list of numbers and (ch:chars) for list of characters.

But roll-your-own is still better than cryptic.

> The name  eratosthenesFilter  is ok, but since there is no other
> eratosthenes around, no meaning is lost by shortening it to simply
> eratosthenes . Not to mention that the conventional term is "sieve", not
> "filter". The documentation has to elaborate on it anyway.
> The generality of the name  num  hints that a single letter name is
> preferable.
> The names that I think are great because they are to the point are
>  factors
>  primes
> I have some resistance to use nouns for functions. In the imperative world,
nouns are for
variables, verbs are for functions. I know that in pure functional
programming there is not such a thing
as variables, but still I would reserve nouns for function parameters and
bound expressions. Hence if I have a function that
find factors, I would call it findFactors rather than just factors.

One such example of misnaming - from a beginner point of view -  is the
length function in prelude: if it was called
count, I believe more beginners would have realized that works by actually
counting the elements of
a list and not  by accessing to some already available 'property' of the

> > Out of curiosity, there is any reason why you called the auxiliary
> function
> > 'go' ?
> Convention. Often, an auxiliary function that does basically the same
> thing as the main function  factors  but with an extra parameter will be
> named  factors' . The apostrophe has the drawback that it's easy to
> forget, so some people now name such auxiliary functions  go  instead.
I tend to use _ instead of '. Is more visible and keep conveying the idea
that the auxiliary function
is just a slight variation of the main one.

> Regards,
> apfelmus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.haskell.org/pipermail/beginners/attachments/20090314/c0692edd/attachment-0001.htm

More information about the Beginners mailing list