Control.Monad.Inception

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).

Your challenge:

  • 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.

Hackage, Cabal and the Haskell Platform: The Second Year

The Haskell Implementors Workshop was held in Baltimore, Oct 1, 2010. Duncan Coutts from Well-Typed and I presented a status report on the Haskell distribution infrastructure:

You can read the slides as PDF here, or online:

The amount of freely available Haskell code has grown exponentially in the past
two years as Hackage and Cabal have come online. Managing millions of Haskell
code, partitioned thousands of interdependent packages is a serious engineering
challenge that has received little attention from the language research community.
Meanwhile, new adopters of Haskell struggle to deal with the sheer number of
libraries and tools now available.

One pragmatic approach to managing this web is the Haskell Platform (HP), a
project to build a blessed, comprehensive set of libraries meeting objective
quality control criteria, and in doing so make expert recommendations on which
packages to use. In its first six weeks of operation the HP had over forty
thousand downloads.

The challenge with such a project is to manage the many conflict constraints
for diversity, coverage, and quality when assembling the package set. This talk
will outline the state of the Haskell Platform, the technical approaches taken
to build it, and the roadmap ahead.