Syntax extension for Monads in Ocaml Jacques Carette, Lydia E. van Dijk and Oleg Kiselyov This Camlp4 extension provides some syntactic sugar to beautify monadic expressions. Example: A simple but realistic example of the use of a list monad looks like this bind [1; 2; 3] (fun a -> bind [3; 4; 5] (fun b -> return (a + b))) where we assume the appropriate definitions of the functions "bind" and "return". With the help of "pa_monad" this can be written as perform a <-- [1; 2; 3]; b <-- [3; 4; 5]; return (a + b) which is much clearer and thus easier to understand and maintain. By the way, the expression evaluates to [4; 5; 6; 5; 6; 7; 6; 7; 8] the sum of each pair of values of the input list
In denotational semantics and functional programming, the terms monad morphism, monad layering, monad constructor, and monad transformer have by now accumulated 20 years of twisted history. The exchange between Eric Kidd and sigfpe about the probability monad prompted me to investigate this history
Just fire up your REPL and see for yourself how the malleable syntactic structures of the language grow in front of your eyes, alongside your program. Whether this is through Lisp macros or Ruby meta-programming or Scala control structures, the secret sauce is in the ability to implement more and more powerful abstractions within the language. But what makes one language shine more compared to another is the ability to combine abstractions leading to more powerful syntactic structures. Recently people have been talking about the Maybe monad and its myriads of implementation possibilities in Ruby. Because of its dynamic nature and powerful meta-programming facilities, Ruby allows you to write this .. @phone = Location.find(:first, ...elided... ).andand.phone Here andand is an abstraction of the Maybe monad that you can seamlessly compose with core Ruby syntax structures, effectively growing the Ruby language.
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.
Our favorite iconoclast, Erik Meijer, presented a very interesting talk at a recent GOTO Chicago event, Functional Programming Night. He originally planned on doing his popular "Fundamentalist Fu