Dear Mike,
It might be worth noting that JavaScript is a functional language. (It has a lambda operator ("function"), closures, and can pass functions as parameters and return values.) However, because it has eager evaluation, the whole monad business does not apply, at least not in the way it applies to Haskell.
In fact, JavaScript is probably the most widely used functional language on the planet.
I think you're confusing the existence of first-class functions with functional programming. Functional programming avoids state and mutable data. It emphasizes the application of functions, in contrast to the imperative programming style, which emphasizes changes in state.
It's certainly possible to write functional programs in any of these languages, but it takes a lot of conscious effort--in fact, I'd say it's harder to write a functional program in JavaScript because of the myriad of strange ways state changes occur.
I used the term "functional [programming] language" on purpose (as opposed to "functional programming style"), because of your statement
So there's not a lot of call for learning a functional programming language either.
which I feel might be wrong. I meant that JavaScript is a functional programming language in the same way in which ML/OCaml/F#, Lisp, and Scheme are (just uglier, slower, and running in a sandbox called "browser"). These are considered functional languages by many, and their categorical semantics has been studied. (Well, the semantics of idealized versions.) JavaScript is just riddled with some syntactic and semantic ugliness that makes it unattractive for formal study, but that doesn't make it un-functional in principle.
I'm not sure what you mean by "the whole monad business does not apply". There are lots of monads, each doing something different. There are several monadic parsers I know of in JavaScript, for instance. Here's a monad for making JavaScript be lazily evaluated instead of eager: function e(x) { return function() { return x; } } function m(x, y) { return function () { return x()(y()); } }
Doesn't very fact that JavaScript allows you to write down the delaying monad give away its functional-language nature? And doesn't the existence of monadic parsers in JavaScript underpin that it might be beneficial for real-life programmers to learn some functional programming? By "monad business" I meant using monads to introduce side effects to lazy languages like Haskell, I could have been clearer there. Categorically, your monad is of a different kind, as I shall now sketch. (Just in case anyone is interested.) First, we need to observe that it is not straightforwardly a monad in the categorical sense. The reason is that the naturality square of the "unit" e does not commute. Considering that underlying functor T of the monad-in-spe sends a morphism f to T f = lambda g.lambda().f(g()) the naturality square would be e \circ f == (lambda g.lambda (). f(g())) \circ e which fails iff the f has a side effect (in the widest sense, which includes going into an infinite loop): that effect would get invoked on the equation's left side but not on the right. However, your code *does* represent a monad on the subcategory of (denotations of) effect-free (and terminating) programs. Categorically, (T, m, e) corresponds to an attempt to define a strong monad on an *unspecified* subcategory of the symmetric premonoidal category (not CCC!) that models your eager language (long story...). Fortunately, such a categories exist: e.g. the maximum one is given by all morphisms w.r.t. which your unit-in-spe is natural, but again that's a long story. At any rate, from a categorical and conceptional point of view the delaying "monad" on an eager language differs from Haskell-style monads. Happy holidays, Carsten http://www.cs.bath.ac.uk/~cf/ [For admin and other information see: http://www.mta.ca/~cat-dist/ ] Status: RO