The distinction is that in a pure FP language, Autrijus' emminently clever code would not be possible.

The inclusion of the monad into the previously pure FP Haskell, is testiment to the practical restrictions that pure FP implies. There are some tasks that FP algorithms are far and away the best alternative. There are some tasks that imperative algorithms (with their inherent utilisation of side effects) are more practical.

Once you remove the "no side-effects" aspect from FP, you end up with the main distinction between FP and imperative code being the syntax used. For some algorithms, a declarative syntax is the most clear and concise. For some algoriths, a recursive definition is the easiest to code, understand and maintain--whether using declarative or imperative syntax. For some algorithms, good ol'imperative loops and blocks and side-effects is just the ticket.

My preference--and there is no implication in this that seeks to restrict anyone else to my choices--is for a language that supports all these styles of syntax, without artificial restristions. For me, currently, the best choice available is Perl, which is why I come back to Perl in preference to all the other languages I've tried over the last few years.

My conclusion from Autrujus' example, is that to address the constraints imposed by my posted problem (memory), the requirement is to utilise side-effects. What Autrujus demonstrated was that this can indeed be done within Haskell.

So, we reach the point where the given task can be tackled in both languages, so the choice of language comes down to personal preference--mine is Perl.