Joel Reymont wrote:
So when should I use a STM TChan instead of a regular Chan?
On Oct 31, 2005, at 10:08 PM, ChrisK wrote:
Or perhaps a TChan, if that is more appropriate:
http://www.haskell.org/ghc/docs/latest/html/libraries/stm/Control- Concurrent-STM-TChan.html
I like the curried command idiom:
I'm not sure I understand this. Are you trying to show that the same logToParent approach can be used with Chan, TChan and MVar below?
do chan <- newChan let logToParent = writeChan chan
do tChan <- newTChan let logToParentSTM = writeTChan tChan let logToParent = atomically.logToParentSTM
do mVar <- newEmptyMVar let logToParent = putMVar mVar
Thanks, Joel
Yes, exactly. I listed several alternatives. The logToParent approach hides the actualy mechanism in use. This has 2 advantages: * You can switch the code for logToParent without messing with the child code (or type signatures!) The Chan/TChan are non-blocking while the MVar (or TMVar) would block, so this is a non-trivial difference. * The child has no reference to the data structure so the only thing it can do is write/put via logToParent. If you had passed the chan/var to the child then it could accidentally start reading from it. Which would be bad. All this is an example of the "Haskell is the best imperative language" saying. An OO language might need a whole class/inferance structure to support what "writeChan chan" accomplished by currying. -- Chris