Question about 'Tackling the Awkward Squad'

[Don Wakefield]

I posed the following question on comp.lang.functional, and a helpful
reader emailed me to suggest that I should ask it here. Briefly, I
dabble in Haskell to exercise my mind in a way that my C++ heritage
doesn't, so if I'm asking silly questions or missing seemingly obvious
notions, I beg forgiveness.

The Question. I was reading Simon Peyton Jones' fascinating paper:

   Tackling the awkward squad: monadic input/output, concurrency,
   exceptions, and foreign-language calls in Haskell
       (the January 9th 2001 draft)

when I ran across what appears to be an error. On page 34, while
discussing Channels, he proposes a function called dupChan:

   dupChan (read, write)
     = do { new_read <- newEmptyMVar ;
            hole <- takeMVar write ;
            putMVar write hole ;
            putMVar new_read hole ;
            return (new_read, write) }

The rationale is given thusly:

 "For example, consider a multi-cast channel, in which there are
  multiple readers, each of which should see all the values written to
  the channel ... The idea is that the channel returned by dupChan can
  be read independently of the original, and sees all (and only) the
  data written to the channel after the dupChan call."

But earlier he has defined getChan thusly:

   getchan (read, write)
     = do { head_var <- takeMVar read ;
            MkItem val new_head <- takeMVar head_var ;
            putMVar read new_head ;
            return val }

Since the line which performs the 'takeMVar head_var' leaves the MVar
referenced by head_var empty, the dupChan 'new_read' Stream should block
when the reader tries to *also* use getChan on this Stream, isn't this
so? Am I missing some subtlety? I drew all the pictures :^)~

-- 
Don Wakefield                              Mentor Graphics Corporation
(503) 685-1262                             8005 S.W. Boeckman Road    
don_wakefield@mentorg.com                  Wilsonville, OR 97070-7777