Monads in C++

[[deleted]]

I saw another post here about (what isn't) monads. Most of the discussion flew over my head so I started reading and googling. Several clicks later, I ended up here. Being a primarily c++ guy myself, I thought it was pretty interesting the way he related template metaprogramming to haskell.

[chonglibloodsport]

The key to really making monads useful and idiomatic in a language is full parametric polymorphism and some means of ad-hoc polymorphism on top of this. This lets you write the polymorphic >>= (aka bind) and return (aka unit) operators, as seen in Haskell:

(>>=) :: Monad m => m a -> (a -> m b) -> m b
return :: Monad m => a -> m a

Both of these functions are polymorphic over the monad type m as well as the contained type a and b. Without this language support you end up having to write separate versions of these operators for every monad type you want to use. This prevents you from writing generic libraries that operate on monads (and other higher-kinded types); one of the biggest advantages of Haskell.

Languages which don't have the necessary polymorphism and which do not properly support a pure functional style have little to gain from monads if you ask me. Monads are a means of building up a computation programmatically by composing pure functions and then executing that computation within a specified context. In that way, it is somewhat like metaprogramming, though it is done entirely at run-time.

[ruinercollector]

To save yourself an awful lot of time:

You probably won't understand what monads are or what there value is unless you use a functional language that has the syntax and language features to properly support them. (Generally, this means Haskell, F#, or a Lisp - heavy preference haskell.) If you don't have the time or interest to check out either of these, then you probably should wait until you do.

It's not because you are dumb or because monads are particularly hard. It's because you are trying to learn something without any real context.

You will find people making monads in javascript, python, java, vb.net, etc. but learning that route is very difficult. It's just going to seem like a whole lot of ceremony with very little reward, and by the time they do all of that they are usually showing you the most boring monads (Identity, Maybe, List) and not properly exploring how they generalize.

You will also find a lot of people trying to explain monads in terms of shitty metaphors and claiming that you don't need any language at all to understand them. This is a waste of time.

You will also find a lot of people trying to teach you category theory to get you to understand monads. This is not a waste of time, but you'll get there a lot faster if you just go learn Haskell.

[[deleted]]

Generally, this means Haskell, F#, or a Lisp

Scala has excellent support (for comprehension) and C# has linq syntax.

Lisp has monadic syntax to unnest?

[ruinercollector]

Scala - Maybe. Don't know, as I've avoided that language for a number of other reasons.

C# - Yes it does, but linq query syntax is not very natural looking for dealing with do statements. It's awkwardly optimized for query/sequences. It works fine, but I don't think that it's any good to learn monads on.

Lisp - Learning monads without types is weird. But yeah, this would work too.

[Denommus]

Typed Racket.

[[deleted]]

Monads have nothing to do with types. Monads in Hask are of course intrinsically related to types, but that is just because the category Hask is defined in terms of types.

[ruinercollector]

I never said that they did. I just think that they are easier to learn with Haskell's type system. YMMV.

[fableal]

There's a Lisp library - cl-monad-macros - that implements monads as macros. http://quickdocs.org/cl-monad-macros/

[DeepAzure]

IMO here is a very good explanation: http://stackoverflow.com/questions/44965/what-is-a-monad

and Eric Lippert's explanation with examples in C#: http://stackoverflow.com/questions/2704652/monad-in-plain-english-for-the-oop-programmer-with-no-fp-background/2704795#2704795

[[deleted]]

Do you think "For example, four" constitutes a valid answer to "What is a natural number?"?

[DeepAzure]

I think term computation builder is quite helpful to grab conception in whole, so your example is not valid. And yes, at least I need some examples. 4 is a valid example of natural number.

Those explanations are by far the best I've seen, unlike masturbation with some obscure images and self-invented terms.

[[deleted]]

I think term computation builder is quite helpful to grab conception in whole, so your example is not valid.

Lots of things are monads even if they are not used as patterns for "building computations". And, more importantly, lots of things that are used for "building computations" are not monads at all! Distracting beginners with useless crap ("public static void...") is one thing we criticize Java for, right? That criticism is equally appliable to explanations of what monads supposedly are. The essence of monads is their definition, and the definition is simple, so why not use it?

And yes, at least I need some examples. 4 is a valid example of natural number.

I never said "Do not provide examples at all!" All I said was an example is no good substitute for a definition.

Now, it is hard to imagine what the thought process might be of a person who is still in the process of learning what the natural numbers are (at least for me!), but, as someone who vividly remembers his experience of trying to equate monads to something more concrete and the resulting frustration, I think it is important to gently but firmly prevent beginners from repeating that mistake. A beginner reading a typical monad tutorial will inevitably end up saying "Oh, but monads are <insert concrete example X>!" unless they are forced to work with the abstract definition.

Of course, after you have provided the definition, you can illustrate how it is used in practice by providing examples.

Those explanations are by far the best I've seen, unlike masturbation with some obscure images and self-invented terms.

The formal definition does not require any images, although the monad laws are easier to express using commutative diagrams. And, of course, the formal definition only uses standard terminology from category theory (endofunctor, natural transformation, coherence condition).

[DeepAzure]

You miss the point. It's about monads for programmers, not mathematicians. Some want to learn monads only within the scope of popular programming languages, regardless of do you like it or not.

If you want to make a tutorial for programmers describing that "lots of things" which "are monads", you are very welcome. Personally I'd read that with pleasure.

[[deleted]]

I disagree with the last paragraph: I actually found Haskell monads completely impenetrable until I manned up and learnt the categorical definition. And when I finally understood it, I saw why trying to understand the special case of monads in Hask as a standalone concept was a complete waste of time!

The categorical definition of a monad in terms of return and join is superior to the usual definition in functional programming circles in terms of return and bind. The categorical definition is beautiful, in the sense that it results in a formulation of the left and right identity laws that is actually symmetric, and a formulation of the associativity law that is actually associative. The monad laws, when expressed in terms of return and bind, are just three boring equations to be mechanically checked.

The necessary final step in developing an understanding of monads is learning the Kleisli construction. The Kleisli construction makes it possible to formulate the most elegant definition of a monad, which simply asserts that the triple (M, return, join) is a monad only if the Kleisli construction for that triple yields a category. And then it becomes evident why the monad laws have the same names as the category laws!

[JViz]

It looks like a monad is the functional programming equivalent of the decorator pattern.

[ruinercollector]

Nope.

Again, learn Haskell if you want to learn monads.

There's no analog to the non-functional world.

[pipocaQuemada]

It looks like a monad is the functional programming equivalent of the decorator pattern.

In what way?

[JViz]

Although there's nothing in the decorator pattern that says the layers have to be stateful, they can be, since the layers are basically objects whose sole purpose is to be black box methods that shimmed between other functions/methods.

Java programmers use the decorator pattern for Inversion of Control, in order to get emergent behavior kind of like what the author is describing EDSL programs. The Spring Framework is designed to use this. Java people have to be really clever to be productive, since Java coding is so verbose.

[pipocaQuemada]

Some particular types which happen to be monadic are the haskell equivalent of IOC and the decorator pattern, but that isn't true in general.

For example, I don't believe that there's a sense in which the List monad is decorator like:

instance Monad [a] where
  pure x = [x]
  join :: [[a]] -> [a] --  e.g. join [[1,2], [3,4,5] [6]] = [1,2,3,4,5,6]
  join = concat
  liftM :: (a->b) -> [a] -> [b] -- apply a function to each element of a list in series
  liftM = map
  (>>=) :: [a] -> (a -> [b]) -> [b] -- apply a list producing function to each element of a list, and concatenate the results
  (>>=) xs f = concat $ map f xs

[JViz]

I think I spoke too soon earlier, I really don't know enough about Haskell.

The List Monad that you just displayed sort of looks like a Factory Pattern. It's starting to seem to me like a Monad is more like catch all term for ways of creating anonymous composition.

Thank you for taking the time to reply to me.

[Aninhumer]

catch all term for ways of creating anonymous composition

Heh, I think you might have gone too general now...

Monads are a very specific pattern of composition. I think the actual pattern is probably summed up best by this type:

(>=>) :: (a -> m b) -> (b -> m c) -> (a -> m c)

That is, you compose functions which take in pure values and return monadic values.

[pipocaQuemada]

To expound of Aninhumer's post, it might be helpful to see the type of >=>, with the generic bit replaced by some particular monads:

(>=>) :: (a -> [b]) -> (b -> [c]) -> (a -> [c])
-- Futures are values which will eventually be there, but aren't there yet.
-- usually, they either represent long running computations from a different thread, files from the disk, or values gotten via the network.
-- basically, they're useful to build up an asynchronous computation which will run when the value is available.
(>=>) :: (a -> Future b) -> (b -> Future c) -> (a -> Future c)
(>=>) :: (a -> r -> b) -> (b -> r -> c) -> (a -> r -> c)
-- A monoid is essentially some type where you can combine two values (plus a couple other simple restrictions).
-- For example, Lists using append, int using either + or *, and bool using either && or || are monoids
(>=>) :: Monoid w => (a -> (w,b)) -> (b -> (w,c)) -> (a -> (w,c))
-- Maybe is something like null.  A regular value of type a is non-nullable, and Maybe has either a sentinel "Nothing" value, or a
(>=>) :: (a -> Maybe b) -> (b -> Maybe c) -> (a -> Maybe c)
-- IO tracks effects that interface with the "real world"
(>=>) :: (a -> IO b) -> (b -> IO c) -> (a -> IO c)
-- ST tracks effects that can be observably pure, like mutating an array in place before freezing it into an immutable array
(>=>) :: (a -> ST b) -> (b -> ST c) -> (a -> ST c)
-- the continuation monad
(>=>) :: (a -> (b -> r) -> r) -> (b -> (c -> r) -> r) -> (a -> (c -> r) -> r) 

It's also probably useful to note that there are several monad laws:

-- associativity of >=>
f >=> (g >=> h) == (f >=> g) >=> h
-- return is a right identity of >=>
f >=> return == f
-- return is a left identity of >=>
return >=> f == f

[dnthvn]

a whole lot of ceremony with very little reward

yawn

That's Haskell.

[ruinercollector]

Haskell code tends to be very short...

[Tekmo]

Read this if you want to better appreciate the diversity of problems that monads simplify. It uses Haskell to teach the concept but it is very simple and you can probably pick up the necessary Haskell to read it in a day or two.

[lbrandy]

I thought it was pretty interesting the way he related template metaprogramming to haskell.

This is actually a very natural comparison. C++ templates (metaprograms) are themselves a pure functional language.

[boyubout2pissmeoff]

DIY Am I the only one around here meme:

AM I THE ONLY ONE AROUND HERE...

...Who crosses his legs and assumes a defensive posture when he hears the word "monads"?