Total Functional Programming Here's an interesting paper recently mention in another thread: Total Functional Programming... Abstract: The driving idea of functional programming is to make programming more closely related to mathematics. A program in a functional language such as Haskell or Miranda consists of equations which are both computation rules and a basis for simple algebraic reasoning about the functions and data structures they define. The existing model of functional programming, although elegant and powerful, is compromised to a greater extent than is commonly recognized by the presence of partial functions. We consider a simple discipline of total functional programming designed to exclude the possibility of non-termination. Among other things this requires a type distinction between data, which is finite, and codata, which is potentially infinite. I presume that the bogus definiton of "fib" is a subtle reminder of the importance of eliminating bottom.
Tom Schrijvers, Peter Stuckey and Philip Wadler Abstract: A constraint programming system combines two essential components: a constraint solver and a search engine. The constraint solver reasons about satisfiability of conjunctions of constraints, and the search engine controls the search for solutions by iteratively exploring a disjunctive search tree defined by the constraint program. In this paper we give a monadic definition of constraint programming where the solver is defined as a monad threaded through the monadic search tree. We are then able to define search and search strategies as first class objects that can themselves be built or extended by composable search transformers. Search transformers give a powerful and unifying approach to viewing search in constraint programming, and the resulting constraint programming system is first class and extremely flexible. Let's briefly look at the n queens example from the paper. First, there is the nqueens model:
Suppose someone stole all the monads but one, which monad would you want it to be? If you're a Haskell programmer you wouldn't be too bothered, you could just roll your own monads using nothing more than functions. But suppose someone stole do-notation leaving you with a version that only supported one type of monad. Which one would you choose? Rolling your own Haskell syntax is hard so you really want to choose wisely. Is there a universal monad that encompasses the functionality of all other monads? About a year ago I must have skimmed this post because the line "the continuation monad is in some sense the mother of all monads" became stuck in my head. So maybe Cont is the monad we should choose. This post is my investigation of why exactly it's the best choice. Along the way I'll also try to give some insight into how you can make practical use the continuation monad.
Comonads are an abstraction from category theory dualing many qualities of Monads. They are conceptually much simpler than arrows but seem to offer a solution to some problems not easily solved by monads. The ideas presented here are not novel except for the comonadic combinators for a nicer syntax. Typeclass Combinators Reader State Stream Writer Links
L. Schröder, and T. Mossakowski. Fundamental Approaches to Software Engineering (FASE 2003), volume 2621 of Lecture Notes in Computer Science, page 261--277. Springer; Berlin; http://www.springer.de, (2003)
D. Walter, L. Schröder, and T. Mossakowski. Algebra and Coalgebra in Computer Science, volume 3629 of Lecture Notes in Computer Science, page 424-438. Springer; Berlin; http://www.springer.de, (2005)
S. Goncharov, L. Schröder, and T. Mossakowski. Mathematical Foundations of Computer Science, volume 4162 of Lecture Notes in Computer Science, page 447-458. Springer; Berlin; http://www.springer.de, (2006)