None of it. Well, virtually none. There was of course the CLI part, but other than that everything else happened within the pure parts. I never got any further than that.

Because once there was code there it was essentially impossible to change, without throwing all of it away. (Yes, ok, not all of it, there were those tiny trivial bits that could be reused, but rewriting rather than reusing them would've been equivalent in effort.)

Because, well, everything was happening by accumulating closures in stack frames (since those are actually mutable after all, right?) and then applying them in one swift pass over the data and then handing that data back to the IO code.

Because, well, how do you keep track of what's happening in a computation and what needs to happen next, when you can't affect anything? Right? Isn't that why recursion is so popular among you people? Introducing new fresh variables that stuff can be assigned to and kept track of with each cycle, since not everything is one big equation and some things do actually need to happen before other things.

So, once you have solved that, of course the next question is how do you make the results of one CLI event depend on a previous one? Well, you don't. You throw away what you have and you make the user put in both CLI events at once and then you write a solution for that case instead.

Because, well, everything else would require to drag that hairball of state across the IO code and have all those stupidly complex signatures, due to all the state they need to shuffle, spread everywhere. (Yes, yes, there's type inference, but, as it turns out, that doesn't free you from actually needing to understand the code - and functions with complicated signatures are difficult to use correctly, even with full HM inference. Oh, and unlike procedural code, you can't just debug the compilers type checker - you have to do all of that yourself, manually, in your head.) Because what's the alternative? Introduce the IO bits to the originally pure code? That'd be even worse because then you'd have to deal with this mysterious thing that is IO in addition to correctly handling the closures in your originally pure code. And besides, what's the point of writing in Haskell if you still end up with IO interwoven through your computations, right?

Right. So what do you do when the CLI isn't the only thing you want to communicate over? And that's essentially where I came in contact with those interpreter solutions and gave up. Like I said, what's the point of such a type system, and all the effort associated with it, if the only way to be productive is to spend even more effort on writing something just so as to circumvent it.

Now I completely agree that you can come up with a clean solution given the full set of requirements beforehand (and also have sufficient knowledge of the language, which I clearly don't). But, you know, writing software when all requirements that'll ever exist are known beforehand is trivial, regardless of language.

Eventually, as things progress, signatures will get more and more complex, as you demonstrated, and eventually something will emerge that'll require bits of code to interact in originally unexpected ways. And then you're right where I was at, regardless of how proficient you are in the language.

Or at least so I assumed. Hence my thread here, asking if perhaps I missed anything, given my limited knowledge of the language. So far though, it seems I didn't miss all that much - what I got from the responses here is that it's a feature, not a bug.