Haskell is a purely functional programming, which is to say that mutability is generally absent and expressions have referential transparency. Purity and the accommodations required for it to function gracefully should not be underestimated as an influence on the rest of the language, and it is a powerful point of comparison. Where an impure language will change, a pure one will force you to recreate, modification is replaced by taking the original and creating something new using it. This has a great many benefits regarding predictability, consistency, and safety of programs, but it also induces a considerable change in mode of thought when programming. Haskell also does not truly have statements, do-notation may superficially appear to reveal some sort of statements in the language, but this is mere syntactic sugar, though it does reflect quite powerfully how monads may be used to model imperative semantics. Referential transparency is a useful consequence of purity, and it implies that an expression may be replaced by the value it evaluates to without changing the program (only partially, it may change the actual computations done of course, but the point of the matter is that the results are the same); a consequence which follows from referential transparency is that expressions may not have side effects.

However, to echo the common wisdom that no pure principle will survive practical work, purity, taken to its extreme, destabilized by its own rigidity, will pass over into its negation. In our case this manifests quite clearly in the realm of I/O, which presents a particularly intractable difficulty for any pure language. The reason why is clear to see when we consider how referential transparency could hold under output specifically, how can any expression sending the outside world arbitrary information and with the executive power to read arbitrary information in from the world be expected to be referentially transparent? How may any function be expected to be pure and give us the same results for the same inputs when it may read input from the outside world? The answer, of course, is that it may not be expected to do such a thing, and the languages solution to this situation is as cunning as it is practical. Monads have been anticipated in this discourse above, regarding imperative semantics, but they will find their true relevance now. Within Haskell, IO is to be done through a monad, which holds a value, and allows you to run a function using what it contains, however, the function must return (mandated and enforced by types) a value within the same monad. For example:

main = do x <- getline
reverse x
putStr x

Here we may use the line input arbitrarily, in our computations, but we may not take it outside of the monadic context. This solution does, however, introduce additional difficulty for those learning the language, as it is an unusual and uncomfortable thing to deal with compared to an impure language such as Lua.