Or you can use an effect system (however that doesn't give you the opportunity of overriding IO functions, but I think that providing such an opportunity with the means you suggest (splitting IO into many sub-monads) is not going to be usable in the large scale)
By the way, I am surprised that there seems to not exist any non-purely-academic language at all that supports effect systems! (except for Java's checked exceptions being a poor analogue). The only language with an effect system *and* a compiler that I know of is DDC, but it seems to be purely experimental. 2009/10/7 Ketil Malde <[email protected]>: > Peter Verswyvelen <[email protected]> writes: > >> So yes, without using IO, Haskell forces you into this safe spot > > One could argue that IO should be broken down into a set of "sub-monads" > encapsulating various subsets of the functionality - file system, > network access, randomness, and so on. This could extend the "safe > spot" to cover much more computational real estate, and effectively > sandbox programs in various ways. > > So instead of 'main :: IO ()', a text processing program using stdin and > stdout could have type 'main :: MonadStdIO m => m ()'. For testing, you > could then define your own monad implementing 'putStrLn' and 'readLn' > etc, and a function 'runStdIO :: MonadStdIO m => m () -> String' that > you are free to use in your quickcheck properties. > > (ObAttribution: I think it was a posting by Lennart Augustsson on unique > names that brought this to my mind, but a quick googling didn't find > that exact mail.) > > -k > -- > If I haven't seen further, it is by standing in the footprints of giants > _______________________________________________ > Haskell-Cafe mailing list > [email protected] > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Eugene Kirpichov Web IR developer, market.yandex.ru _______________________________________________ Haskell-Cafe mailing list [email protected] http://www.haskell.org/mailman/listinfo/haskell-cafe
