[plt-scheme] Common history among streams, continuations, and monads?

From: Anton van Straaten (anton at appsolutions.com)
Date: Sun Jul 8 17:19:42 EDT 2007

Grant Rettke wrote:
> Is there some greater theory to streams and
> continuations? 

Yes, lots!  Read SICP, PLAI... (After HtDP, of course.)

> I know of them as language features, but not more than
> that.

The language features are just a tease, really.  The theory is where the 
interesting action is.  With the theory, you don't need the language 
features as much.

> In Haskell, those were replaced with doing IO via monads. Have they
> all got something in common? Some shared thread?

Sequencing.

The connection between streams and sequencing should be obvious.  The 
connection between monads, continuations, and sequencing is also easy:

Monads are a pattern for using continuation-passing style to make 
control flow explicit, which is commonly used to enforce sequencing.

> I'm still reading up on what is so great about monads. It concerns me
> when loads of folks say that "It is too complicated, don't worry about
> it, just know that it is pure and that they work." 

In the Haskell context, it makes sense to tell beginners not to worry 
about the details, because if the goal is just to e.g. perform I/O, the 
details of monads aren't very relevant to that purpose, and would be 
confusing.  Essentially, in Haskell the man behind the curtain is more 
visible than he is in other languages, but that doesn't mean you 
shouldn't ignore him anyway.

In other contexts, the need for monads is less: sequencing is not a big 
deal in most non-lazy languages, and the ability of monads to pass state 
from one computation to the next is not a big deal for impure languages. 
  So outside of the Haskell context, you don't use monads just because 
you have to, but because you have some more subtle reason to.  That 
usually requires that you understand monads a bit better.

> I know someone
> understands, I just haven't found that someone writing up a concise
> explanation yet.

Monads are very general, so any concise explanation only touches on 
their capabilities.  In one sense, monads just provide a way of 
sequencing operations on a data type.  But if you pull the camera focus 
back about 30,000 feet, monads define a skeleton for a purely functional 
representation of an infinite set of possibly-imperative programming 
languages.  Then again, maybe those two descriptions amount to the same 
thing.

You really need to get your hands dirty, no description alone is likely 
to do it.  Try working through this:

   http://okmij.org/ftp/Scheme/monad-in-Scheme.html

Anton



Posted on the users mailing list.