[arzke]

> Referential transparency is related to the concept of "function purity" (in the sense that either one usually guarantees the other), which you will often hear people talk about as well.

Isn't referential transparency (the property of a function that allows it to be replaced by its equivalent output) a consequence of function purity? In other words: could a pure function not be referentially transparent?

Also, I remember Robert C. Martin describing the functional programming paradigm as a "restriction upon assignment". I kind of like this definition as the rest seems to flow from it: if you can't assign, you can't mutate. If you can't mutate, you have pure functions, which are referentially transparent.

[corinroyal]

"Could a pure function not be referentially transparent?"

Yes there are pure functions which are not referentially transparent. A pure function with side effects, such as printing a result to standard output, is not referentially transparent. You can't replace the function with it's return value, since that doesn't replicate the printing side effect.

[kaba0]

A pure function is by definition side-effect free. What you write makes 0 sense. Maybe thinking of total functions?

But not all FP languages have to be so puritan to only allow pure functions, most have escape hatches and it is just good form to prefer purity (even in more mainstream languages!). The most common way to circumvent this problem is through a Monad, which very naively put, just a description of the order of side-effecting functions, and their inter-dependencies. This will later get executed at a specific place, e.g. the main function -- the point is, that a large part of the code will be pure, and much easier to reason about.

[arzke]

I thought that a pure function could not have side effects by definition. Would you mind sharing your definition of a pure function?