Yes, you can use this pattern to define a mini-interpreter for a stream of
events or commands, where each event is represented as a data structure.
For example, I've used this pattern to write little scripts, a a collection
of maps, for driving an integration test.
–S
On Monday, May 25, 2015 a
Stuart Sierra,
Thank you for the response. I won't take that talk as encyclopedic.
The 'chain-consequences' function is very interesting, though it is
unfamiliar to me. I am still learning about Clojure.
You mention that the State/Event pattern is a common one. If you were
talking about archi
This is a pattern I have used **occasionally**.
That whole talk is just patterns that were in my head at the time. Take
whatever you find useful from it, but don't treat it as a universal or
complete list.
If you squint, that 'chain-consequences' function behaves sort of like a
monad, but I wo
Thank you for that. I'm curious, when Stuart Sierra mentions a "sequence
monad", does he offer this example simply to keep the Haskell programmers
happy, or is he suggesting that Clojure programmers sometimes use this
pattern? I am especially puzzled by this code that he offers, since this
does
Almost any event-sourcing system is built like this. Datomic is
(more-or-less) an example of this as it tracks all past transactions and
keeps indexes that are aggregates of the entire state of the DB.
In addition, Greg Young introduced a event store at CodeMesh 2013 that uses
this model: https://
