Re: [Haskell-cafe] Re: Point-free style

just a few quick observations comming from an imperative background, I found point free code very difficult to understand when learning Haskell. It is not that it is hard to understand the concepts of point-free style, it is that it is hard to know when something is point-free. It is "another option" and I think the best way to make a language "readable" is to stick to a few simple rules and clean semantics. Since, you can't write all your code point-free, I say write it all pointed - consistency is the thing! also, the term "point free" confused me for quite a while. Point-free code has lots of points (periods) and so I kept thinking it was the other way around. matt On 11/02/2005, at 7:19 AM, Henning Thielemann wrote:
On 10 Feb 2005, Peter Simons wrote:
Now compare that to the following function, which does the some thing but without point-free notation:
incrEach' :: Integer -> [Integer] -> [Integer] incrEach' i is = is >>= \i' -> return (i'+i)
point-free again
is >>= return . (i+)
:-]
_______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe

Jerzy pointed out the utility (well, at least the *possibility*) of expressions such as the following when writing points-free code (or perhaps per Matthew it should be "pointy code" :) ): (.) . (.) . (.) This is the function which composes a 1-argument function with a 3-argument function (and the pattern generalizes to n in the second functional argument). I sometimes itch to use the n=2 case, as in the following, but good sense usually gets the better of me: (.<) = (.) . (.) (this allows, for example, concat .< replicate). One gets the impression of some odd kind of Morse code, or perhaps "smileys" / "emoticons" ... The attached file gives some more detail and examples for the points-free fans. -- Fritz
participants (2)
-
Fritz Ruehr
-
Matthew Roberts