Hacker News Reader

Comment by joppy | Hacker News Reader

It is pretty common nowadays in functional programming languages to find operators which reverse the order of application or composition, so rather than writing f(g(h(x))) one can instead write “x |> h |> g |> f”. This style is quite popular, which leads me to believe that many people prefer object-action over action-object in same way. (Although perhaps this is more a critique of action-object-object vs object-action-action)

View on HN

While you didn't refer to any explicit programming language (so your example is correct by definition), I think you may have mixed up something. The order is reversed, but typically not in the way you describe. For your example of f(g(h(x))), you would write (f . g . h) x in Haskell. So for this particular example, the syntactical order is not reversed.

However, you could say the natural order of reading is reversed: The naive way to read (f . g . h) might be "first f, then g, then h", opposite the actual order of execution.

I'm assuming they were talking about Elixir, which uses that syntax to pipe the result of the left side into the first argument of the function on the right side. The transformation was correct in Elixir, and I can confirm that I at least do think that way.

This x |> h |> g |> f syntax is Elixir (and F# perhaps? and surely other langs). In Haskell this is written

  x & h & g & f

And in shell script, this is written

  echo x | h | g | f

This operator is sometimes called the pipeline operator

Anyway, here is some ghci session exemplifying the usage of the & operator

  $ ghci
  λ import Data.Function((&))
  λ a f g h x = x & h & g & f
  λ b f g h x = (f . g . h) x
  λ c = f g h x = f (g (h x))
  λ a (+ 1) (* 2) (+ 3) 1
  9
  λ b (+ 1) (* 2) (+ 3) 1
  9
  λ c (+ 1) (* 2) (+ 3) 1
  9

It's unfortunate that this is named & in Haskell and not |>. And what's worse, it's not in the prelude.

to be honest, idiomatic code in haskell-land tends to be written right-to-left and not left-to-right, so you'd usually write it with the ($) and (.) operators. I personally have gotten used to reading it right to left more, as have probably most people who use haskell extensively. And I think it's only fair that haskell chose a 1 character operator: composing functions and applying them to arguments is the main way to make programs, so it's good that you have to type the least amount characters possible to do it, compared to something like F# where all the function composition and application operator take two characters (|>, <|, >>, <<)

I recently started using (&) a lot (e.g. `something arg1 arg2 & liftIO`) and frankly I think it's fantastic for readability, especially with adaptors like `liftIO` or `void` in `do` blocks. The relevant information is up front in a consistent position in the block; the adaptor is only even noticeable when I actually read the line - rather than being something I need to semi-consciously ignore. I also sometimes use it for chains of pure function application when the alternative is to read bottom-to-top or use where/let bindings with arbitrary names.

`import "flow" Flow` gives you (|>) = ($), (<|) = (&), (<.) = (.) and (.>) (by analogy). I slightly wish it were part of base - the symbols are much more intuitive, and I think that's important for increasing adoption - but I tend not to use it because it's non-standard. Most potential/plausible Haskell users, after all, haven't used Haskell at all, let alone extensively. Such people need to be taken seriously in decision making processes even though they almost necessarily have no voice.

I don't think the number of characters is at all relevant to the decision though: being non-surprising and understandable are far more important than using one vs two chars which in this case pull in both directions and I reckon the balance lies with sticking to the standard.

Reply on news.ycombinator.com