This is actually one of the worst applications in which to use Haskell. Why?
Lots of I/O means that you need to deal with monads; which I would suggest tackling once you become comfortable with the other unique features of the language, not before. They're a complex topic even for those with graduate degrees in mathematics (or so I hear). Not only that, if you start out writing code that's mostly I/O, you may get the impression that you can and should do a lot of algorithms imperatively in Haskell. This is not the case. Perhaps most importantly for you, I'm guessing that you were attracted to this language because of it's almost notoriously short and straightforward chunks of code. This is the case for nearly everything in the language besides I/O and manual memory management (which is I/O, really).
I would suggest writing your program in C, which is perfectly suited for this task, and have your first Haskell programs be things that you would consider rather tricky in other languages. I'm a particular fan of machine-learning algorithms, myself, but whatever data structures or algorithms you seemed to find difficult in other languages, try to rework for Haskell.
Just get used to writing a lot less code. My first major Haskell app was a nueral-network training library that used both reinforcement learning and genetic algorithms, multithreaded. In 350 lines of code (including generous amounts of commenting). That's the serious power of Haskell, in my opinion.