Tue, 20 Mar 2001 18:07:25 +0100 (CET), Andreas Gruenbacher
The sort of lazy evaluation employed in your solution is in a way similar to coroutines, with the following restrictions (correct me if I'm wrong):
* It is not possible to implement cyclic communication.
I see no problem in this. In fact laziness is really about the ability to cycle anything.
* It is not possible to implement processes with multiple asynchronous output channels.
Again I see no problem: splitEvenOdd:: [a] -> ([a], [a]) splitEvenOdd [] = ([], []) splitEvenOdd (x:xs) = (x:ys, zs) where (ys, zs) = splitOddEven xs splitOddEven:: [a] -> ([a], [a]) splitOddEven [] = ([], []) splitOddEven (x:xs) = (ys, x:zs) where (ys, zs) = splitEvenOdd xs What it cannot do is to multiplex input. Code is purely functional and thus the result cannot depend on the order in which inputs become available. Concurrent Haskell provides nondeterministic merge from lazy lists (mergeIO and nmergeIO in module Concurrent). -- __("< Marcin Kowalczyk * qrczak@knm.org.pl http://qrczak.ids.net.pl/ \__/ ^^ SYGNATURA ZASTÊPCZA QRCZAK