In Lazier functional programming, part 1, I suggested that some of the standard tools of lazy functional programming are not as lazy as they might be, including even if-then-else. Generalizing from boolean conditionals, I posed the puzzle of how to define a lazier either function, which encapsulates case analysis for sum types. The standard definition:

data Either a b = Left a | Right b

either :: (a → c) → (b → c) → Either a b → c
either f g (Left  x) = f x
either f g (Right y) = g y

The comments to part 1 fairly quickly converged to something close to the laxer definition I had in mind:

eitherL f g = const (f ⊥ ⊓ g ⊥) ⊔ either f g

which is a simple generalization of Luke Palmer‘s laxer if-then-else (reconstructed from memory):

bool c a b = (a ⊓ b) ⊔ (if c then a else b)

My thanks to Dave for “laxer” as a denotational alternative to the operational term “lazier”.

Note in the either definition that the argument ordering allows computing (f ⊥ ⊓ g ⊥) just once and reusing the result for different values of the third argument. Similarly,

cond :: a → a → Bool → a
cond a b = const (a ⊓ b) ⊔ (λ c → if c then a else b)

Let’s look at some examples:

cond 6 8 ⊥ ≡ (6 ⊓ 8) ⊔ ⊥ ≡ 6 ⊓ 8 ≡ ⊥

cond 7 7 ⊥ ≡ (7 ⊓ 7) ⊔ ⊥ ≡ 7 ⊓ 7 ≡ 7

cond (3,4) (4,5) ⊥ ≡ ((3,4) ⊓ (4,5)) ⊔ ⊥ ≡ (⊥,⊥)

cond (3,4) (3,5) ⊥ ≡ ((3,4) ⊓ (3,5)) ⊔ ⊥ ≡ (3,⊥)

cond [2,3,5] [1,3] ⊥ ≡ ([2,3,5] ⊓ [1,3]) ⊔ ⊥ ≡ ⊥ : 3 : ⊥

These results are more useful than they might at first appear. Monotonicity implies that the following information-inequalities also hold for an arbitrary boolean c:

cond 6 8 c ⊒ ⊥
cond 7 7 c ⊒ 7
cond (3,4) (4,5) c ⊒ (⊥,⊥)
cond (3,4) (3,5) c ⊒ (3,⊥)
cond [2,3,5] [1,3] c ⊒ (⊥ : 3 : ⊥)

In other words, given only a and b, we can already start extracting some information about the value of cond a b c. If c takes a long time to compute (forever in the extreme case), we may be able to get some useful information out of cond before cond gets any information out of c. Moreover, the presence of “⊔” hints at parallelization. Evaluation of a ⊓ b can proceed in one thread, while another computes the standard conditional.

At the function level,

cond 6 8 ⊒ const ⊥
cond 7 7 ⊒ const 7
cond (3,4) (4,5) ⊒ const (⊥,⊥)
cond (3,4) (3,5) ⊒ const (3,⊥)
cond [2,3,5] [1,3] ⊒ const (⊥ : 3 : ⊥)

This observation is handy when cond is partially applied to two arguments and the resulting function is reused. We can even compute a ⊓ b once and share the results among many calls.

These same considerations apply more generally to the laxer either definition above.

Does the definition of either above really satisfy the conditions of the puzzle, and how did I come up with it? A key insight is that monotonicity implies the following two inequalities for all a and b:

eitherL f g ⊥ ⊑ eitherL f g (Left  a)
eitherL f g ⊥ ⊑ eitherL f g (Right b)

Consistency with the defining equations then imply that

eitherL f g (Left  a) ≡ f a
eitherL f g (Right b) ≡ g b

so

eitherL f g ⊥ ⊑ f a
eitherL f g ⊥ ⊑ g b

and hence

eitherL f g ⊥ ⊑ f a ⊓ g b

Specializing to a ≡ b ≡ ⊥ gives us an single least of these upper bounds:

eitherL f g ⊥ ⊑ f ⊥ ⊓ g ⊥

similarly to Albert’s reasoning for the similar case of if-then-else.

I asked for a information-maximal version of eitherL so as to get as much information out with as little information in, in the spirit of lax (non-strict) functional programming. For the maximal version, choose equality:

eitherL f g ⊥ ≡ f ⊥ ⊓ g ⊥

There are three fairly simple proofs remaining, namely that (a) this equality holds for the definition of eitherL above, (b) the use of (⊔) is legitimate in that definition, and (c) the definition as a whole is consistent with the defining equations.

Finally, note that lub (⊔) is used in a restricted way here. In this use u ⊔ v, not only are the arguments u and v information-compatible (the semantic pre-condition of lub), but also, u ⊑ v. This property shows up in several applications of lub, and I suspect it can be useful in efficient implementation.

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. Besides True and False, 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.

Sums

Now consider a broader example, taken from the standard Haskell prelude, namely sum types and corresponding case analysis:

data Either a b = Left a | Right b

either :: (a → c) → (b → c) → Either a b → c
either f g (Left  x) = f x
either f g (Right y) = g y

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.

Products

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).

fu :: () → Int
fu () = 2

fp :: (a,b) → Int
fp (x,y) = 3

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:

q :: Bool → (Int,Int) → Int
q b (x,y) = if b then 3 else x

Haskell semantics says that q True is strict, rather than being equivalent to the non-strict function const 3.

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 either above.

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 either.
• The meaning of either f g must 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.

A puzzle

I’ll end this post with a puzzle: what is a minimally strict interpretation of the definition of either above? Backing up,

• Is there a meaning for either that 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.