foo = uncurry (.) . (map . second . drop . length &&& (filter . (flip $ flip isPrefixOf . snd)))

foo

foo p [] = []

foo p ( (k,l):os ) | p `isPrefixOf` l = (k,take (length p) l) : foo p os

| otherwise = foo p os

goo = uncurry g . (foo &&& bar)

goo i = foo i `g` bar i

f `interspersedBy` g = uncurry g . f

goo = (foo &&& bar) `interspersedBy` g

I discovered that programming in Point-Free Style can be addictive! Today, I wrote two perverse functions using PFS before discovering I had spent almost two hours just two add two lines to my code!!!Here's the one of the two:Sorry if it didn't fit in your screen. I used the namepurposedly: can you imagine what this function does?If you can't come up with a solution in less than 1 minute, the above code is a failure as it means nothing to you (i.e. its meaning is not apparent).Try with the following version:Sorry for the bad layout.It took two hours to me to figure out how and where to put all those . and $ in the first version but it was fun, just like winning a game.On the other hand, I wrote the second version as I was writing this post. I think the reason why I write PFS code much much slower lies both in my lack of knowledge of PFS programming and my way of reasoning about programs.Nevertheless, PFS is appealing to me because I'm used to write shell scripts to automate things on the systems I manage: PFS is all about composing and piping functions, mostly like you compose and pipe shell programs.I wonder if I'll be able to guess the meaning of the PFS functions I wrote after some months: we'll see.As a side note, I noticed that the following pattern is coming up rather often when coding in FPS:which means:So, I wonder whether the following combinator would help to making FPS code more readable:So, the above snippet would become: