Q:

Can a Haskell program resemble objects passing messages to each other?

Haskell is a purely functional language, breaking from traditional object-oriented languages. However, consider the following quote from Alan Kay on the "true" meaning of OOP:

OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things. It can be done in Smalltalk and in LISP. There are possibly other systems in which this is possible, but I’m not aware of them. -- Alan Kay

and later on:

I thought of objects being like biological cells and/or individual computers on a network, only able to communicate with messages (so messaging came at the very beginning -- it took a while to see how to do messaging in a programming language efficiently enough to be useful).

I'm curious to what extent this style of programming can be achieved in Haskell. In particular, is it possible to structure a Haskell program as a sequence of (something resembling) encapsulated objects passing messages back and forth to each other?
NOTE: I'm looking for examples specific to Haskell, not functional languages at large (when in conflict).

A:

only messaging, local retention and protection and hiding of
  state-process
like biological cells and/or individual computers on a network, only
  able to communicate with messages

I believe certain Haskell programming patterns do resemble Kay's description, to a degree.
In streaming libraries like conduit, pipes or streaming, it is common to build a computation as a pipeline composed of different stages. Each part of the pipeline is quite independent of the others and can maintain its own private state (you can have "shared" state in the pipeline as well).
The topologies tend to be linear and unidirectional. That said, abstractions like conduit's ZipSink—and the Applicative instance for Folds in the foldl package—let you build "tree-like" topologies that branch out. And pipes can be bidirectional, although I haven't seen many examples that make use of it.
Then there's arrowized functional reactive programming. It lets you build "circuits" of automaton arrows that can even include loops. Each part of the circuit can maintain its own state. As the description of the netwire FRP library states:

This library provides interfaces for and implements wire arrows useful
  both for functional reactive programming (FRP) and locally stateful
  programming (LSP).

And from the docs of the auto library:

auto works by providing a type that encapsulates value stream
  transformers, or locally stateful functions; by specifying your
  program as a (potentially cyclic) graph of relationships between value
  streams, you create a way of declaring a system based simply on static
  relationships between quantities.
Instead of a state monad type solution, where all functions have
  access to a rigid global state, auto works by specifying relationships
  which each exist independently and on their own, without any global
  state.

