Tag: monad

Control.Monad.Inception

~ Don Stewart ~ 2 Comments

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.

Practical Haskell: scripting with types

~ Don Stewart ~ 14 Comments

I had the pleasure to give a new talk today, on design in functional programming — types, abstractions and monads — using the motivating example of scripting. The slides are below and a PDF version is available.

Shell scripts are often a quick, dirty way to get the job done. You glue
together external tools, maybe do a little error checking and process all data
as strings. This is great for some very simple problems but as requirements
change and more is demanded from the code shell scripts become unwieldy and
fragile. When they get large, they become slow and difficult to maintain. If
you need to write robust code then shell is not the way to go.

In this talk at an alternative: how to use Haskell as a type checked and
natively compiled language for scripting tasks. By refining the semantics of
the problem domain, employing abstraction, we produce shorter and more robust
code, that is more maintainable and scalable.