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
4
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-4.12.0.0/docs/Control-Monad.html exists and the functions in it do not need to be rewritten for each type of monad
4
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