[Haskell-cafe] First time haskell - parse error!

[Tillmann Rendel]

Ketil Malde wrote:
> 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?

I don't. I would not expect to understand the behavior of a piece of 
code just by reading its name.

However, a good name can help you understand the purpose of the code 
while reading it, and after reading the code, you may link the name to 
the same concept as the original author did. This way, the original 
author can help you rediscover his understanding of the problem by 
structuring the code accordingly.

But that means that names should not be introduced to break long 
expressions into short ones, but to point out structure. For example, 
the structure of the oddSquareSum example is a (.)-pipeline. We could 
highlight this fact by giving a name to each function in the pipeline.

   oddSquareSum
     = sum . belowLimit . onlyOdd . squareAll $ numbers
     where
       belowLimit = takeWhile (< 10000)
       onlyOdd = filter odd
       squareAll = map (^ 2)
       numbers = [1..]

However, in this version of the code, we obfuscate an important aspect 
of the structure of the pipeline: It is a pipeline working on lists. I 
would like to make this more visible, e.g. like this:

   oddSquareSum
     = sum . takeWhile belowLimit . filter odd . map square $ numbers
     where
       belowLimit x = x < 10000
       square x = x * x
       numbers = [1..]

In this version, we see the structure of the code in the pipeline, and 
the details in the local definitions. Furthermore, I would expect a 
reader to be able to remember the meaning of the names after having read 
the definitions.

   Tillmann