For a long time, the use of these Monad structures has been restricted to a very small circle of languages, many of them purely functional (mainly due to problems related to the management of the IO).
Recently, these structures have also been adapted to imperative languages

My question is: we talk about same design pattern, Monad, but what is the difference in the implementation of a monad in a purely functional language with respect to the same design pattern but implemented into of the imperative programming ?

What change? Sure not change the idea, but if we talk about of same design pattern implementation but into 2 different programming paradigm something must be different, probably the same information will come back, but we are using identical idea but in 2 different paradigms contexts so the side effect cannot be the same otherwise it would not have occurred to us to implement the monad for imperative language

  • "Recently, these structures have also been adapted to imperative languages" Are you asking about code that generalises over (all) Monads, or code that uses something that is a Monad? The latter has been present in imperative languages for a while, however talking about it's monadic properties is relatively recent
    – Caleth
    Commented Apr 15, 2019 at 11:24
  • code that generalises over (all) Monads because I want to understand better the difference between 2 implementation that comes out when we choose 2 different programming styles, In imperative programming we have side effects but for me is not clear why if 'function' in functional programming representation can use a model to allow to describe function itself to a series of steps, that is a way to produce side effects that is that say that imperative update is a functional model
    – Jack Rock
    Commented Apr 15, 2019 at 11:38
  • For example In a pure functional language, such as Haskell, all functions are without side effects, and state changes are only represented as functions that transform the state, which is explicitly represented as a first class object in the program
    – Jack Rock
    Commented Apr 15, 2019 at 11:39
  • so do you mean whats the difference between e.g. haskell typclasses and scala implicts? or e.g. how do you do higher kinded types in Java (spoiler: you can't)?
    – jk.
    Commented May 14, 2019 at 11:55

2 Answers 2


The main thing I can think of is that in e.g. Haskell Monad can be captured as a typeclass in a library and so does not have to be just a design pattern. This also means you can write functions on Monads once e.g. http://hackage.haskell.org/package/base- exists and the functions in it do not need to be rewritten for each type of monad

  • 1
    This doesn't have anything to do with being functional or not, though. It is a feature of the type system, not whether or not the language enforces referential transparency. E.g. Scala is an OO language that doesn't enforce referential transparency, and it can express the type of a Monad (all you need for that is higher-kinded generics), and it can even express type classes as a design patterns (using implicit objects and implicit parameters). There are research languages that are essentially Java + higher kinds, and those can express monads, too. Commented Apr 14, 2019 at 6:56
  • @JörgWMittag but if although pure functional languages are non-imperative, they often provide a facility for describing the effect of a function as a series of steps. Ok, but what this 'conversion method' is used to describe it as a series of steps? For example In a pure functional language, such as Haskell, all functions are without side effects, and state changes are only represented as functions that transform the state, which is explicitly represented as a first class object in the program.
    – Jack Rock
    Commented Apr 15, 2019 at 11:19
  • I don't understand if 'function' representation use a model to allow to describe function itself to a series of steps
    – Jack Rock
    Commented Apr 15, 2019 at 11:19
  • @JörgWMittag you are, of course right, this isn't strictly speaking related to functional nature of a language but HKTs, I think its still a valid observation though as OP seems to be comparing pure functional languages (which probably means Haskell) to imperative langauges that have recently added monads (which I took to mean C# & Java)
    – jk.
    Commented May 14, 2019 at 11:44

An Imperative Monad is an Object

Every time a function on an object is called, its representation is updated, causing the next function call to possibly respond differently.

The difference you are looking for is in how that Object maintains its state.

  • A Functional style Object would maintain an append-only internal representation.
  • An Imperative style Object would maintain a mutable data structure.

Append Only Data Structures

The big advantage of an append only data structure is that it support transactions, and data-sharing out of the box. For Read Only operations this is a free lunch multiple threads can be reading the same version of the data without needing any synchronisation because the data will not change.

For writers this can be fine too, as long as the only individual interested in the modifications is the writer itself. Each writer simply grows the structure in their own direction, only sharing the common past. When those updates need to be shared you will need a synchronisation mechanism to serialise, verify updates, and publish a reference to the new version.

There is a disadvantage to these append only structures, their memory is never released under active load. This leads to a massive memory leak if there is never a point in time when the slate is wiped clean. Database engines suffer from this issue, and go to great lengths to monitor who is using what version so that the engine can free memory that will never be read from again.

Mutative Data Structures

Conversely Imperative Style Objects have the exact opposite benefits. They can only safely be used by one thread (unless some very careful design is used), they are historically amnesic, and excluding a coding error they keep a tight rein on the memory they consume.

This makes them great for situations where:

  • memory is constrained,
  • they are only infrequently shared,
  • up to the moment state is necessary

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.