Hacker News Reader

Comment by sevensor | Hacker News Reader

I'm no expert in functional programming, but this feels a bit inside-out and backwards to me. It's writing f(g(h(x))) as x.h().g().f(), which doesn't read like function composition to me. If anything, the comprehensions already built into Python look more natural and more functional:

   (f(v) for v in (g(u) for u in (h(w) for w in x)))

The dots in the x.h().g().f() notation also suggest mutation (since we're calling methods on objects here) in a way that makes me uncomfortable.

But like I said, I'm no FP expert. My objections are basically aesthetic. Maybe if I used it, I'd learn to like it.

View on HN

The way you read x.h().g().f() is essentially the same way you read it in F# (with |>), Haskell(with . ,although it goes the opposite direction) and R(with %>%).

It is one of the most aestetically pleasing attributes of use in the functional languages

So the thing that looks less like the function composition I know from algebra is more idiomatic in FP and more pleasing to the FP cognoscenti? I fear my familiarity with FP may be even more deficient than I thought. I could understand writing f . g . h, but what we're talking about here is written more like Unix pipelines. In which case, I could forgive overloading the bitwise or operator, which is already left-associative. You could then do x | h | g | f.

Again, this is a purely aesthetic argument -- the intent of the library seems unclear to me from its syntax. If it's beautiful and clear to you, I'm not going to object to your using it. Aesthetics aside, I don't think there's anything wrong with this library.

Here's how you could hack up a pipe operator in Python:

    class Funk:
         def __init__(self, f):
             self._f = f
         def __or__(self, other):
             return Funk(lambda *_, **__: other(self(*_, **__)))    
         def __call__(self, *args, **kwargs):
             return self._f(*args, **kwargs)

This lets you do fun stuff like:

    pipeline = Funk(h) | Funk(g) | Funk(f)
    pipeline(x)
    pipeline(y)

And that makes me happy that I participated in this discussion.

I'm kind of surprised nobody's done this before. Unless they have. Any pointers to more fully fleshed out implementations of this idea?

You could actually simplify even more with the trick used in a comment farther down (https://github.com/0101/pipetools). That way you would implement __or__ on for example `pipe` and not have to wrap each function.

As it turns out, implementing that different syntax in pyfunctional wouldn't be too hard or API breaking I think. Mainly it would require 1) wrapping/exporting functions to a module you could bring into scope (eg `from functional import functions as F` or `from functional.functions import *`), 2) Writing wrapper code to provide something functionally similar to `pipe`.

On libraries, I swear I saw something a while back, but my googlefu just now didn't help me find it.

Reply on news.ycombinator.com