(->> onions
      dice add-pan fry (add-pan kale) fry serve))

No, but seriously, you can think of (->> foo bar baz quux)

As a way of saying:

    Within the context of computing one thing and passing 
    that result to the next thing with a common carrier 
    object of "foo", do bar, then baz, then quux within
    that context, each operating on foo.

    with someFile
        readIt()
        processIt()
        writeIt()

By the way, monads are a way to abstract this even further so that not only can you model the context of "do something to a thing then do the next thing then do the next", but almost every other kind of context you could think of.

EDIT: as has been pointed out, this isn't really a monad, but it's an example of something monad-like that helps me grasp the larger concept better. Also, fixed the syntax.

To GP: I've heard it called "double arrow" or "post-threading operator".

b) expanding macros for didactic purposes can also aid understanding

but mostly a)

Ultimately, I always fall back on programs not having a good concept of "consuming" or otherwise changing a variable. This is clearly doable, and elsewise it was referenced as linear typing (new to me).

  contents = open(&ramen);
  add_into( &pot, waterfactory() );
  add_into( &pot, contents );
  add_heat( &pot );
  sleep( RAMENCOOKTIME );
  tasty_ramen = open(&pot);

The trick, to me, is that the "type" of "pot" is not fixed in this. Since I consider the "type" to be dependent on its state. I know this can be done with generic and higher order programming, but usually not with the same reference. That is, each call would create a new reference to pot such that the next one fed off of that. Thing is, that doesn't read well. (I mean, it does for toy examples, but doesn't for long ones.)

Make sense?

    type Recipe = Food -> Food
    serve . fry . addPan kale . addPan (dice onions) :: Recipe