Haskell as a Purely Functional Programming Language: Fact or Fiction?

Does Haskell truly embody the concept of functional purity? This question arises frequently among developers, and opinions are often divided. The essence of functional purity lies not just in the absence of side effects, but in how it is explicitly handled through syntax and type rules.

Functional Purity and Side Effects

When discussing functional purity, it's important to distinguish between languages that allow side effects and those that do not. A common counterargument is, "I won't mutate variables in my C, Java, or JavaScript code; I don't need to worry about Haskell's functional purity." While this is true in a technical sense, the core issue lies in the type system and how it enforces functional purity.

To illustrate, consider the following example: in Haskell, sqrt and print are both functions. However, print has side effects, specifically outputting something to the console, while sqrt does not. The presence or absence of side effects is determined by the type system, not by language convention or developer discipline.

Functional Purity in Haskell

Haskell's functional purity is not an absolute standard, and there are caveats, such as the unsafePerformIO function. While unsafePerformIO allows for side effects, it is explicitly marked as unsafe, indicating a deliberate breach of functional purity. This means that functional purity can be controlled using Haskell's features for distinguishing between pure and impure expressions.

Without functional purity, a language cannot provide the guarantees that it ensures no side effects. In languages like Java, C, or JavaScript, you can imagine a type system that enforces functional purity, but this is just imagination until it is implemented. Haskell, on the other hand, provides a rigorous and enforced type system that supports functional purity to a high degree.

Realistic Use Case for Functional Purity

My interest in the purist notion of functional purity in Haskell comes from its ability to express more precise and meaningful code. Java, for instance, has attempted to approximate functional purity with annotations and constexpr in C. However, these features do not provide the same level of enforcement and discipline found in Haskell.

Truly pure languages, if they exist in the standalone sense, are rare. In theorem proving, for example, a program is a proof of a theorem T. A program corresponding to T with the correct type signifies that the theorem is true and does not necessarily need to run. This is a unique and specific use case that diverges from general programming.

Conclusion

Haskell's functional purity is not a standalone feature for everyday programming. Instead, it is a value proposition that enhances code clarity and correctness, particularly in domains that require rigorous reasoning and guarantees. Its purity, while not absolute, is a significant distinction that sets it apart from other languages, making it a valuable tool in the programmer's arsenal.

Keywords: Haskell, Functional Purity, Pure Functional Programming