> In functional programming, a monad is a structure that represents computations defined as sequences of steps. A type with a monad structure defines what it means to chain operations, or nest functions of that type together. This allows the programmer to build pipelines that process data in steps, in which each action is decorated with additional processing rules provided by the monad. As such, monads have been described as "programmable semicolons"; a semicolon is the operator used to chain together individual statements in many imperative programming languages, thus the expression implies that extra code will be executed between the statements in the pipeline. Monads have also been explained with a physical metaphor as assembly lines, where a conveyor belt transports data between functional units that transform it one step at a time. They can also be seen as a functional design pattern to build generic types.
I've never used monads, but what you say makes me think of something:
Suppose I had a Javascript array of functions. And I pass that array into another function that performs that series of functions in order while maybe doing something in between each one. For example, maybe I can pass that list into a function that checks to make sure the result of each call isn't null or undefined. Or maybe I can pass the same list into another function that checks to make sure none of the results are NaN. Would this be an example of monadic behavior?
Yeah. That somewhat resembles monadic behavior. Passing a container (list in this case) of functions and applying each of those functions to a container (again a list in this case) of arguments sounds a lot like an applicative functor. All monads are applicative functors though. Doing something in between each call definitely is more monadic than applicative, since that's more or less what the bind (>>=) function can do.
http://en.wikipedia.org/wiki/Monad_(functional_programming)