From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.science.mathematics.categories/5419 Path: news.gmane.org!not-for-mail From: =?ISO-8859-1?Q?Carsten_F=FChrmann?= Newsgroups: gmane.science.mathematics.categories Subject: Re: additions Date: Fri, 25 Dec 2009 09:18:47 +0100 Message-ID: References: <4B3368C1.3000800@bath.ac.uk> <7f854b310912240825s39f195b2x2db16cc8f3a5cde7@mail.gmail.com> Reply-To: =?ISO-8859-1?Q?Carsten_F=FChrmann?= NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1261773365 14881 80.91.229.12 (25 Dec 2009 20:36:05 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 25 Dec 2009 20:36:05 +0000 (UTC) To: Mike Stay Original-X-From: categories@mta.ca Fri Dec 25 21:35:58 2009 Return-path: Envelope-to: gsmc-categories@m.gmane.org Original-Received: from mailserv.mta.ca ([138.73.1.1]) by lo.gmane.org with esmtp (Exim 4.50) id 1NOGt7-0003b2-Ik for gsmc-categories@m.gmane.org; Fri, 25 Dec 2009 21:35:53 +0100 Original-Received: from Majordom by mailserv.mta.ca with local (Exim 4.61) (envelope-from ) id 1NOGXD-0002xc-4N for categories-list@mta.ca; Fri, 25 Dec 2009 16:13:15 -0400 In-Reply-To: <7f854b310912240825s39f195b2x2db16cc8f3a5cde7@mail.gmail.com> Original-Sender: categories@mta.ca Precedence: bulk Xref: news.gmane.org gmane.science.mathematics.categories:5419 Archived-At: 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/ ]