You're essentially describing functional reactive programming. You end up with the system being described as pure, reactive values and plugging IO based streams in at the edges.
Have a look at the wiki description (http://www.haskell.org/haskellwiki/Functional_Reactive_Programming) and especially the Reactive library (http://www.haskell.org/haskellwiki/Reactive). Theres been a fair amount of work on using frp for distributed, network-orientated systems. Flask (http://portal.acm.org/citation.cfm?id=1411203.1411251) and Opis (http://perso.eleves.bretagne.ens-cachan.fr/~dagand/opis/) are particularly interesting. Opis really shows the value of using pure functions by allowing the same reactive system to be run in production, attached to a debugger, run in a step-by-step simulator or run in a model checker without altering the systems code. On Wed, Nov 5, 2008 at 12:12 AM, Jason Dusek <[EMAIL PROTECTED]> wrote: > Informally, a "pure program" an executable such that the > stream of bytes entering it totally determines the stream of > bytes leaving it. > > Many useful programs that I would like to write in Haskell > don't fall into this category -- for example, network servers > -- but a lot of their components do. Can these components can > be Haskell functions without IO in their signatures? > > Though that seems reasonable, it is not, in general, true. For > example, System.Info.os is generally treated as pure, > though it is not. It's not clear to me how to disambiguate > these "born again" values from really pure values. > > -- > _jsn > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe