Re: additions

["Carsten Führmann" <c.fuhrmann@bath.ac.uk>]

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/ ]