Sebastian Fischer
I do not agree that introducing names locally for compositions is *always* a bad idea, even if used only once.
Well, of course I do that all the time too. :-)
(Choosing names that are "misleading or flat out wrong" is of course always a bad idea.)
Of course nobody actually does this on purpose, but like comments, names tend to bit-rot over time as code gets updated, but names or comments stay the same. Also, good names are harder than they sound: I don't think 'belowLimit' is a good name for 'takeWhile (<10000)', for instance. I certainly couldn't guess what it was for without looking at the implementation, which kind of defeats the purpose of names for improving code clarity, don't you think? And what's a good name for the associative monoid operator again?
Named values are just like comments
While you wanted to degrade named values by this statement I think it can serve as justification.
It does cut both ways, I suppose :-)
With the names in the rewritten example this comment is no longer necessary.
I'm not so sure - the names just try to put meaningful labels on the internals of 'oddSquareSum', while the comment refers to the whole function, and it can be picked up by haddock, so there are other considerations.
Good names can help making comments less important.
OTOH, comment can give you the best(?) of both worlds, both revealing the linear structure of the function, while still providing extra information: oddSquareSum :: Integer oddSquareSum = sum -- add together . takeWhile (<10000) -- until a value >10K is seen . filter odd -- all the odd . map (^2) -- squares of $ [1..] -- natural numbers -k -- If I haven't seen further, it is by standing in the footprints of giants