[dmitriid]

Basically, the moment you have

  readFile  :: FilePath -> IO String
  writeFile :: FilePath -> String -> IO ()

and any function invoking those two (and any functions invoking these function etc. etc.) your "haskell strictly conforms to FP definition" flies out of the window.

And yes: I used the term "IO monad" incorrectly.

[willtim]

These functions do not perform IO, they return IO actions that can be further composed. They are invoked from other functions that also return IO actions, again no IO is actually performed until the top-level final composite action is run by the runtime.

All composition of IO actions is performed with full referential transparency and adherence to the Wikipedia definition.

[dmitriid]

Potato potato. In the end, when the program is run, functions will be run, and side-effects will be executed.

Moreover, if you invoke these functions multiple times they will produce different results.

Hence, no strict adherence to FP principles.

[willtim]

> Moreover, if you invoke these functions multiple times they will produce different results

No this isn't true! Again, you clearly do not yet understand Monads. Please read Phil Wadler's paper.

What you have successfully demonstrated, is that the JavaScript snippets you have been advocating are not sufficient to understand Monads.

[empath75]

> if you invoke these functions multiple times they will produce different results.

the io monad is a pure function that produces impure code for the haskell runtime to execute (this isn't exactly accurate, but i think is an okay way to think about it). It will always produce the same impure code, and so is itself pure.

[dmitriid]

Riight. The "Platonic ideal" again. "It's not the language it's the runtime!"