Proposal: Applicative => Monad: Call for consensus

[wren ng thornton]

On 1/17/11 12:22 PM, Tyson Whitehead wrote:
> On January 15, 2011 22:43:32 Jan-Willem Maessen wrote:
>> For example, I find it relatively easy to
>> understand>>= in the continuation monad, but have to spend a long
>> time puzzling my way through join.
>
> It's not that bad once you get used to thinking of it.  Join simply merges an
> inner computation into an outer one.

I've been doing a lot more of that lately, or rather _not_ doing it. In 
particular, there's often a desire when working in monads like IO to do 
some computation now (and share it) and then do some computation later 
(possibly many times). The natural way of doing this is to have your 
function return IO(IO X) where the outer IO is run now and the inner IO 
is run later. If you want to do both of them now you just call join.

One example where this is especially helpful is when dealing with file 
handling based on commandline flags. In most programs we'd like to run 
the commandline sanity checks as early as possible so that we can fail 
fast, but the actual file manipulation can happen much later and far 
away from main. In the conventional (>>=) style of thinking ---often 
seen in imperative languages--- we'd have to do something like open the 
files early and then pass filehandles throughout the program (or worse, 
pass the file names throughout the program and open/close the files 
repeatedly). This is not only against what we'd like to do, it's also 
unsightly, error prone, and a maintenence nightmare.

But once we switch over to a join style of thinking, the IO(IO X) 
approach becomes obvious. We simply check the flags now and return a 
thunk that will manipulate the file later. We have to pass the thunk 
around, but the action encapsulates whatever we want to do with the file 
rather than being the file itself. An added benefit of this style is 
that it allows us to keep the code that verifies commandline flags close 
by the code that makes use of that information, instead of smearing it 
across the whole program and loosing track of the interrelatedness.

-- 
Live well,
~wren