Question

I would like to know all possible means of side effects in functional languages, even theoretical and not used in practice.

I know about Monads (Haskell) and Uniqueness types (Clean). Are there any other possibilities?

Answer 1

In Mercury everything is pure by default (even IO), and it’s impossible to to write impure code without using rarely needed features.

Pure IO is handled in a similar way to Clean (I believe), by using uniqueness and a state-of-the-world parameter. Mercury considers uniqueness to be a mode property rather than a type property though. (A “mode” in this context is more or less a data-flow direction)

But Mercury also has a static purity system. Some code is recognised by the compiler as impure (calls to the foreign language interface, or to known impure functions/predicates, accessing mutable variables, and a few other cases). Such code must be explicitly declared impure or it is a compiler error. Since the compiler is aware of the impurity, it doesn’t perform reorderings or other optimisations that could affect the impure code. If at some level you can provide a pure interface around the impure operations, you can promise to the compiler that a function/predicate is in fact pure. Otherwise the required impurity declarations propagate all the way up to the main predicate; if you’re prepared to do this you could essentially program imperatively in Mercury (it wouldn’t be fun though).

Mercury also has a concept of semipure code. This is code that does not have a side effect the operation of any other semipure or impure code (pure code by definition is unaffected by side effects from any other code), but may be affected by side effects from other impure code. This extra level of information means that calls that are only not pure because they ‘see’ side effects but doesn’t have any themselves can still be optimised much more freely by the compiler; they can be optimised away if their results are not needed, and they can be reordered so long as they aren’t moved “over” an impure call.