In Haskell they like it better if a function returns the same value if it is called with the same arguments later on. Just like sin( pi ) gives the same answer every time you call it. If you start writing functions that take a file name and return the bytes then that function might return a different value the next time it is called assuming the file contents changed on disk. The same line of reasoning applies to db calls, user i/o, anything with random numbers etc.

But I'm not taking a file name, I'm taking a stream of data, for which the output should always be the same. This should be good enough for applications that deal with standard in and standard out, yes?

Though that's a good point, when it comes time to be opening files on the disk, it inevitably becomes stateful again.

I think this roughly corresponds to the original I/O system in Haskell, based on lazy streams. They were, by all accounts, an absolute bitch to program with. Continuation based I/O was slightly better, but monads were still greeted as liberators when they arrived on the scene.

In fact, you can have functions of type [Byte] -> [Byte], however, the problem is when you need to get the first set of bytes from a file or stdin. You could sort of read this as a function of type FileHandle -> [Byte], which will only very rarely even return the same value twice, let alone guaranteed-always.