(1) Function as a system of N concurrent inputs and 1 output is easy essence. How about function as N concurrent inputs and M concurrent outputs? I think it's not native to lambda calculus. So "system's programming" (if we ever had such paradigm) would solve this issue, while criticizing all FP. (2) For me, I hope this category (What *not* to use Haskell for) won't include SOA. That's what I'am currently trying to decide. (3) I think if CPU's would be lambda-based, not imperative, and paradigm be stronger, most of the "why *not* to use Haskell"'s would be solved, and imperative would be in opposition instead.. with it's enthusiasts. =) They would have good answers for your question. -- View this message in context: http://www.nabble.com/What-*not*-to-use-Haskell-for-tp20436980p20755239.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com.