But surely, the compiler could have figured this out at least?

Hm. One way of reading it is that Haskell defaults to assuming that all functions are pure unless a monad is used, in which case they aren't. And it's the programmer that has to know to when to use the monad. Which goes back to my "monads are a complicated form of flag". Yes, I know it's more complicated than that...

Perl is the other way around. All functions are impure unless the programmer knows otherwise. It would be possible to use (say) attributes to allow the programmer to mark functions pure and the compiler could automemoize them on that basis. Maybe there is even a module idea in there somewhere.

For sure, Perl does no where near the depth of analysis that ghc does--but that is true in almost every area. Objects for instance. And maybe it's not possible without strict typing. But it is also a concious choice on behalf of the the language designers, hence Perl 6 won't have HM-style type checking either.

Is that the right decision? You'd have to argue that with Mr Wall. But without Perl's transparent coersion between strings, integers and reals (and Big::*), Perl would not be Perl.

Haskell and Perl go about achieving what they do--programs--in different ways. We all know that. This is not (for me) about which is better. It's about whether Perl could benefit from the inclusion of a monad type mechanism, to which I say emphatically no. Even if it could be implemented, without an HM-style type system, and a deep analysing compiler, it would be another manual process adding a drain on performance, without the benefits. Adding HM-style type checking to Perl (or any dynamic language) would be fairly impractical, but even if it was practical, I personally wouldn't want it. If I wanted that, I wouldn't be using Perl.

Haskell (often) sells itself on the strength of a few elegant snippets--like the quicksort routine using list comprehensions, but when you look beyond those snippets, much of the gloss is tarnished. It's a little like the Quantum::Superpositions module. When you first encounter it, especially the documentation in the form of what I am sure was a spectacular presentation, it really wows you. But when you look inside, you realise--as someone here commented--it's just a bunch of loops. That doesn't make the module any less powerful in what it does--though it is a little slow for some of it's less esoteric possible uses. What it does mean is that when you understand how it does what it does, the wow factor of the documentation/presentation fades somewhat. If the documentation was less wow, more down to earth, it might engender less ire. I'm pretty certain that Junctions will become a big factor in the success of Perl 6, assuming they are documented in a less hyperbolic fashion and are reasoably fast.

Haskell is a fine, powerful, flexible, fast, elegant language--if you like or need that sort of thing and can make the mental shift to that way of thinking. It doesn't need the hyperbole.

I've tried to keep this subthread on topic, but our interaction is rapidly descending into a which is better debate. Unless you think that Perl would benefit from the addition of a monad-like mechanism, I think we are probably done?