Grafting Functional Support on Top of an Imperative Language

[Bill Baxter]

Lars Noschinski wrote:
> * Jarrett Billingsley <kb3ctd2 at yahoo.com> [08-04-05 05:15]:
>> I'm not one to be listened to, but I think the idea behind monads is 
>> to wrap an inherently impure action (like IO) in a functional shell.  
>> In an imperative language, you do something like:
> 
> Monads are an imperative sublanguage. IO Monads (which are the ones able
> to do impure things) are safe, because there is no way to extract the
> information wrapped in the monad.
> 
> So if you do a read, you don't get a "String", you get an "IO String"
> (i.e. an IO monad containing a string). But you can apply functions to
> the IO monad, which operate on the wrapped value and return a new IO
> monad (for example a method parsing the String to an integer).
> 
> For the functional part of the program (all things outside of the IO
> monad), the return value of e.g. readLine is always the same - an IO
> monad representing the action of reading a line of input and therefore
> it is pure.

Hmm, so would it be correct to say that monad is just another way to say 
'impure function'?  It sounds like that's all you're saying.  So just 
like we're going to have 'pure' to isolate the functional code in D, 
functional languages have 'impure' functions that isolate the 
procedural/stateful stuff.  They just happen to give those impure 
functions a ridiculous name.

Seriously why on earth are they called 'monads'?  Sounds like it derives 
from "mono" meaning "one", like "triad" is a group of three things.  So 
'monad' should mean a group of one thing I would thing.  Yet it means 
"impure function".  Really odd.  I hate it when people give things 
terrible non-descriptive names.  But maybe there's a rational explanantion?

--bb