Take the 2-minute tour ×

In Theory mainly concerned with lambda-calculus?, F. G. Dorais wrote, of the idea that the lambda-calulus defines a domain of mathematics:

That would never stick unless there's another good reason. Besides, the schism between cs and math is very recent, I would contend that "functional programming" is actually a math term, historically speaking. More importantly, it would be wrong to use a term different than those who use it most, namely theoretical computer scientists, who are very competent mathematicians by the way.

The idea, I think, is that the overlap between the kind of constructive mathematics that follows the formulae-as-types correspondence, and pure functional programming is so substantial that the core of the two topics is essentially the same subject.

Is this true?

share|improve this question
In so far as computer science itself is a branch of mathematics... yes –  Mariano Suárez-Alvarez Jan 15 '10 at 20:35
Wow, my comments are controversial as of late! For context, this was a reaction to Hans Stricker's suggestion that we should find another name for "functional programming" just because it's a computer science term. However, my earlier question "Anything wrong with 'functional programming' besides the fact that it's a computer science term?" is essentially the same as yours. This was an honest question, I do not have a definite opinion about that. –  François G. Dorais Jan 15 '10 at 21:23
It is not a big deal, but I kinda think this question should be community wiki. I say this because I think any answer will be based on opinion, and that usually implies comm wiki. –  B. Bischof Jan 16 '10 at 1:45

3 Answers 3

up vote 7 down vote accepted

So, I'm a computer scientist working in this area, and my sense is the following:

You cannot do good work on functional programming if you are ignorant of the logical connection, period. However, while "proofs-as-programs" is a wonderful slogan, which captures a vitally important fact about the large-scale structure of the subject, it doesn't capture all the facts about the programming aspects.

The reason is that when we look at a lambda-term as a program, we additionally care about its intensional properties (such as space usage and runtime), whereas in mathematics we only care about the extensional properties (i.e., the relation it computes).[*] Bubble sort and merge sort are the same function under the lens of $\beta\eta$ equality, but no computer scientist can believe these are the same algorithm.

I hope, of course, that one day these intensional factors will gain logical significance in the same way that the extensional properties already have. But we're not there yet.

[*] FYI: Here I'm using "intensional" and "extensional" in a difference sense than is used in Martin-Lof type theory.

share|improve this answer
"Bubble sort and merge sort are the same function under the lens of beta-eta equality" - Not so fast! Even after you have figured out the right algebraic treatment of program state, and have proved that both will give the same outputs on every input, you will still only have proven propositional equality: beta-eta equality is normally something else in intensional type theory. –  Charles Stewart Jan 16 '10 at 14:24
The same function can have wildly (eg, arbitrary towers of exponentials) different runtimes under different evaluation orders. Since even intensional MLTT is consistent with any evaluation order, I don't think the operational properties of purely functional programs have a type-theoretic/logical reading, yet. –  Neel Krishnaswami Jan 16 '10 at 15:48
You can have a monad that specifies the intended computational meaning of a function. Then regular functions of the lambda calculus become denotationally determined, operationally underspecified programs. I'd be surprised, though, if you could fix things so that bubblesort and mergesort are both computational realisations of some underdetermined lambda expression. –  Charles Stewart Jan 19 '10 at 9:38
If you use an omega-rule for list elimination, then bubble sort and merge sort will have the same canonical form. (The necessary infinitary syntax can be represented either in a higher-order fashion, the way Noam Zeilberger does it, or coinductively, the way Girard does in Ludics.) –  Neel Krishnaswami Jan 19 '10 at 11:12
Omega rules aren't syntax! I'm not sure whether they can be functional programming, either. Can you give me a ref (Zeilberger is less taxing than Girard): I'd like to think this through for myself. –  Charles Stewart Jan 20 '10 at 9:14

There is some work in using monoidal category theory in functional programming in languages like Haskell. In addition to simply using the ideas and implementing them, they develop new frameworks for the theory, new applications of the theorems, and presentations of the theory. I say this is a branch of mathematics, but it is a sliding scale depending on how you treat it.

share|improve this answer
This being the mostly categorical theory arising out of Moggi's computational lambda calculus and its applications. –  Charles Stewart Jan 16 '10 at 2:14

I think most people here would agree that Category Theory is part of mathematics.

The study of strongly-typed functional programming languages is really just the study of cartesian closed categories, so I think that this particular part of functional programming is legitimate mathematics. And Domain Theory is the study of the category of complete partial orders with bottom, so I would include that too.

I don't think I would extend that to untyped or dynamically-typed languages (LISP). Also, I'd probably pick a term other than "functional programming" since subfields of math are rarely named with gerunds ("strongly typed functional languages" is probably the most accurate, but a bit verbose).

share|improve this answer
The theory of the untyped lambda calculus is much, much richer than the simply-typed case, and is actually why Scott invented domain theory. Giving a model for it requires finding a category where the isomorphism $D == D -> D$ holds non-trivially, which is a pretty bold thing to imagine. (In fact, Scott wrote a paper arguing against the untyped lambda calculus, on the grounds that there was no way anyone could come up with such a model, shortly before he came up with one!) –  Neel Krishnaswami Jan 19 '10 at 9:37
Scott's model of PCF terms as "simply typed lambda expressions of infinite type" was a work of truly incredible vision, but its result was only to add non-normalizing terms to the simply typed lambda calculus, and the result was still a cartesian closed category. The $D_\infty$ construction does not allow for the sort of blatantly ill-typed terms like (4+"Fred") that are allowed in LISP, Python, Ruby -- nor should it!. –  Adam Jan 19 '10 at 20:16
Er, sure it does. You just take the universal domain to be a coalesced sum including an error case, and blatantly ill-typed stuff denotes the error value. The error is conventionally called Wrong, which is where the "wrong" in the phrase "well-typed programs don't go wrong" comes from. –  Neel Krishnaswami Jan 19 '10 at 23:32

Your Answer


