[Haskell-beginners] Re: Integer factorization
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,
> > 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
> 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
> The names that I think are great because they are to the point are
> 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
> > '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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Beginners