Unfortunately I found it really takes a lot of work on practical programs to get past the stage where you have these sort of doubts. Finding the motivation to d

Unfortunately I found it really takes a lot of work on practical programs to get past the stage where you have these sort of doubts. Finding the motivation to do so can be a chicken-in-egg type of problem. Technically you are incorrect about exceptions needing to change the type of pure functions, but in fact I would always prefer to return an Either and so it does result in code changes up the stack. However it may not mean very many changes to signatures; a function used by only one parent shouldn't be top-level and doesn't need a signature. And the result is a function that captures failure modes in its type, which means other consumers can't forget to handle failure (though they can explicitly choose not to if they want to just throw an exception on failure). This may feel a bit verbose and unwieldy at first but it actually is very powerful once you know the techniques. The concern about IO - you don't say this but a lot of people worry about logging output to STDIO for debugging. But Debug.Trace will do this impurely for debugging purposes. Otherwise its actually pretty rare that you write a pure function that later turns out to need IO. IO should usually stay in top-level functions that provide the over-all program / routine structure. I'm only at a journeyman level with Haskell but I've written over 20,000 lines of real code and can't remember ever really running into this problem, though I did worry about it when just getting started.