Unix pipelines are indeed beautiful, especially when you consider its similarity to Haskell's monadic I/O:
http://okmij.org/ftp/Computation/monadic-shell.html
Unix pipelines actually helped me make sense of Haskell's monad.
Unix pipelines actually helped me make sense of Haskell's monad.
a; b # Execute command b after a. The result of a is not used by b.
a >> b # Run function b after a. The result of a is not used by b.
a | b # Execute command b after a. The result of a is used by b.
a >>= b # Run function b after a. The result of a is used by b.Edit: I might be misinterpreting your use of "execute _after_". You may not mean "after the completion of a" but instead "operating on the results of a, asynchronously" in which case, apologies.
main = getArgs >>= processData >>= displayData
The (imaginary) function getArgs takes no arguments and returns a list of command-line arguments wrapped in an IO monad. The first >>= takes that list and feeds it into the function on its right, processData, which accepts it and returns some other value in an IO monad, which the third >>= accepts and feeds into displayData, which accepts it and returns nothing (or, technically, IO (), the unit (empty) value wrapped in an IO monad) which is main's return value.
See? Everything is still function application, but the mental model becomes feeding data through a pipeline of functions, each of which operates on the data and passes it along.
For pipelines to be monadic, their structure must be able to change depending on the result on the part of pipeline. The type of binding operator hints at it: (>>=) :: m a -> (a -> m b) -> m b.
The second argument receives result of first computation and computes the way overall result (m b) will be computed.
As for program composition, I would like to add gstreamer to the mix: it allows for DAG communication between programs.