This post is inspired by a delightful insight from Luke Palmer. I’ll begin with some motivation, and then propose a puzzle.
Consider the following definition of our familiar conditional:
ifThenElse :: Bool → a → a → a ifThenElse True t f = t ifThenElse False t f = f
In a strict language, where there are only two boolean values, these two clauses have a straightforward reading.
(The reading is less straightforward when patterns overlap, as mentioned in Lazier function definitions by merging partial values.)
In a non-strict language like Haskell, there are three distinct boolean values, not two.
Bool also has a value ⊥, pronounced “bottom” for being at the bottom of the information ordering.
For an illustration and explanation of information ordering, see Merging partial values.
Note: In Haskell code, ⊥ is sometimes denoted by “
undefined“, which can be confusing, because the meaning is defined precisely.
There are many other ways to denote ⊥ in Haskell, and it is impossible to determine whether or not an arbitrary Haskell expression denotes ⊥.
I’ll generally use “⊥” in place of “
undefined” in this post, as well as for the corresponding semantic value.
The two-clause definition above only addresses two of the three possible boolean values explicitly.
What, if anything, does it say indirectly about the meaning of an application like “
ifThenElse ⊥ 3 5“?
The Haskell language standard gives an operational answer to this question. Clauses are examined, using pattern matching to select a clause and instantiate that clause’s variables. In case more than one clause matches, the earlier one is chosen.
Pattern matching has three possible outcomes:
- A single substitution, providing variable bindings that specialize the patterns in a clause’s left-hand side (LHS) to coincide with the actual call. The matching uses semantic, not syntactic, equality and can require forcing evaluation of previously unevaluated thunks (delayed computations).
- Proof of the nonexistence of such a substitution.
- Neither conclusion, due to an error or nontermination during evaluation.
In this example, the effort to match
True against ⊥ leads to the third outcome.
For Haskell as currently defined, the result of the application in such a case is then defined to be ⊥ also.
Which is to say that
ifThenElse is strict (in its first argument).
So strictness is the Haskell answer, but is it really the answer we want? Are there alternatives that might better fit the spirit of non-strict functional programming?
Note: Haskell is often referred to as a “lazy language”, while a more precise description is that Haskell has non-strict semantics, typically with a lazy implementation. I think of programming languages and libraries (at least ones I like using) as having a single semantics, amenable to various implementations. (Haskell falls somewhat short, as explained in Notions of purity in Haskell.) Sadly, I don’t know a pleasant comparative form to mean “less strict”, so I’m using the more familiar term “lazier” in this post’s title. Suggestions welcome.
Again, these two clauses have a clear and direct reading for strict languages, but in a non-strict language like Haskell, there is a third element of
Either a b not explicitly addressed, namely ⊥.
Again, Haskell’s current definition says that
either f g ⊥ == ⊥, i.e.,
either f g is always strict.
Most types can be built up from sums and products. Since we’ve looked at sums already, let’s now consider products. And rather than n-ary products, just look at binary products and the unit type (a sort of nullary product).
Again, these clauses only capture the non-⊥ part of their domains explicitly. And again, the Haskell specification says that these functions are strict.
Here’s a less trivial example:
Haskell semantics says that
q True is strict, rather than being equivalent to the non-strict function
Lazier functional programming
Given that we’re enjoying some of the benefits of a non-strict language and programming paradigm (as described, e.g., in Why Functional Programming Matters), we might enjoy more if we can loosen up some of the strictness of pattern-based definitions.
What might a less-strict interpretation be?
Let’s take the definition of
I’d require any interpretation to satisfy a two conditions:
- The meaning is consistent with the direct explicit readings of the clauses.
When read as equations, those clauses are true of the meaning of
- The meaning of
either f gmust be information-monotonic, i.e., more information in leads to more (and consistent) information out.
For an interpretation that is ideal for non-strict programming, I’ll add a third condition:
- Information-wise, the interpretation is maximal among all meanings that satisfy the first two conditions, i.e., it’s minimally strict.
I’ll end this post with a puzzle: what is a minimally strict interpretation of the definition of
- Is there a meaning for
eitherthat satisfies these three conditions?
- If so, is there exactly one such meaning?
- If so, what is that meaning, and how can it be obtained and implemented systematically?
Edit: *Warning: spoilers ahead in the comments. I encourage you to play with the puzzle on your own before reading on.