I saw Inception a few months ago. At the time I was struck by how coherent the computational environment describe in the movie was. I suspect “Inception” forms a monadic environment for computation (though not necessarily a useful one), and have been meaning to try to implement it. However, time is short, so here are my notes from the time (August 23rd) on the semantics of Inception, in the hope that someone else will implement Control.Monad.Inception.
Semantics of the Inception computational environment
- “Dream” == thread of control == forkIO
- A thread must stay at each level (thread group) for it not to collapse (dreamer)
- Messages can be sent down (music) – e.g. async message passing
- A kick exits a thread up one level (“die”) – throwTo KillThread
- Time degrades quickly 10, 3 mins , 10 mins , 10 years – so adjust scheduler time slices based on levels
- Groups of threads brought together by the dreamer can enter a new environment together (collaborative dreaming) – shared heap
- Arbitrary effects are allowed, (yep, it has IO at the bottom)
- Under sedation, you can disassociate a thread from its control stack, and it is in limbo (some “init” thread group), until it remembers.
- Tokens are (unique) depth counters (0, many).
- Improve Claessen’s “poor man’s concurrency monad” to support the Inception environment.
- What notion of `bind` and `return` are used?
- Show that the monad laws are satisfied.
- import Control.Monad.Inception and win!
Refer to the published analysis on the use of the inception monad you need to be able to support.
2 thoughts on “Control.Monad.Inception”
can this be taken further by saying the dreamers with a dream a limited to the constructs built by the architect … so each level/dream effectively has it’s own namespace.
that movie messed me up to days, i’ve thought about it way too much :)
This movie messed with my mind too. And thanks to you, it’ll continue. I will think about your ideas :p