Difference between revisions of "Avoiding IO"
Jump to navigation
Jump to search
(introduction) |
(longer introduction) |
||
| Line 1: | Line 1: | ||
Haskell requires an explicit type for operations involving input and output. |
Haskell requires an explicit type for operations involving input and output. |
||
| − | This way it makes a problem explicit, that exists in every language |
+ | This way it makes a problem explicit, that exists in every language: |
| + | Input and output functions can have so many effects, that it is hard to combine them. |
||
| + | It is hard to test them, because they can in principle depend on every state of the real world. |
||
| + | Thus in order to maintain modularity you should avoid IO whereever possible. |
||
| + | It is too tempting to get rid of IO by <hask>unsafePerformIO</hask>, |
||
| + | but we want to present some clean techniques to avoid IO. |
||
== Lazy construction == |
== Lazy construction == |
||
Revision as of 12:00, 25 December 2008
Haskell requires an explicit type for operations involving input and output.
This way it makes a problem explicit, that exists in every language:
Input and output functions can have so many effects, that it is hard to combine them.
It is hard to test them, because they can in principle depend on every state of the real world.
Thus in order to maintain modularity you should avoid IO whereever possible.
It is too tempting to get rid of IO by unsafePerformIO,
but we want to present some clean techniques to avoid IO.
Lazy construction
map putStr vs. putStr concat
State monad
randomIO
ST monad
STRef instead of IORef, STArray instead of IOArray
Custom type class
example getText