This post continues from an idea of Ryan Ingram’s in an email thread How to make code least strict?.

A pretty story

Pattern matching in function definitions is very handy and has a declarative feel. For instance,

sum []     = 0
sum (x:xs) = x + sum xs

Simply replace “=” by “==” to read such a set of pattern clauses (partial definitions) as a collection of properties specifying a sum function:

• The sum of an empty list equals zero
• The sum of a (non-empty) list x:xs equals x plus the sum of the xs.

Moreover, these properties define the sum function, in that sum is the least-defined function that satisfies these two properties.

Guards have a similar style and meaning:

abs x | x <  0 = -x
abs x | x >= 0 =  x

Replacing “=” by “==” and guards by logical implication, we again have two properties that define abs:

x <  0 ==> abs x == -x
x >= 0 ==> abs x ==  x

O, the lies!

This pretty story is a lie, as becomes apparent when we look at overlapping clauses. For instance, we’re more likely to write abs without the second guard:

abs x | x <  0 = -x
abs x          =  x

A declarative of the second clause (∀ x. abs x == x) is false.

I’d more likely write

abs x | x < 0     = -x
      | otherwise =  x

which is all the more deceptive, since “otherwise” doesn’t really mean otherwise. It’s just a synonym for “True“.

Another subtle but common problem arises with definitions like the following, as pointed out by ChrisK in How to make code least strict?:

zip :: [a] -> [b] -> [(a,b)]
zip []      _       = []
zip _       []      = []
zip (x:xs') (y:ys') = (x,y) : zip xs' ys'

These three clauses read like independently true properties for zip. The first two clauses overlap, but their values agree, so what could possibly go wrong with a declarative reading?

The problem is that there are really three flavors of lists, not two. This definition explicitly addresses the nil and cons cases, leaving ⊥.

By the definition above, the value of ‘zip [] ⊥‘ is indeed [], which is consistent with each clause. However, the value of ‘zip ⊥ []‘ is ⊥, because Haskell semantics says that each clause is tried in order, and the first clause forces evaluation of ⊥ when comparing it with []. This ⊥ value is inconsistent with reading the second clause as a property. Swapping the first two clauses fixes the second example but breaks the first one.

Is it possible to fix zip so that its meaning is consistent with these three properties? We seem to be stuck with an arbitrary bias, with strictness in the first or second argument.

Or are we?

Unambiguous choice

Ryan Ingram suggested using unamb, and I agree that it is just the ticket for dilemmas like zip above, where we want unbiased laziness. (See posts on unambiguous choice and especially Functional concurrency with unambiguous choice.) The unamb operator returns the more defined of its two arguments, which are required to be equal if neither is ⊥. This precondition allows unamb to have a concurrent implementation with nondeterministic scheduling, while retaining simple functional (referentially transparent) semantics (over its domain of definition).

As Ryan said:

Actually, I see a nice pattern here for unamb + pattern matching:

zip xs ys = foldr unamb undefined [p1 xs ys, p2 xs ys, p3 xs ys] where
    p1 [] _ = []
    p2 _ [] = []
    p3 (x:xs) (y:ys) = (x,y) : zip xs ys

Basically, split each pattern out into a separate function (which by definition is ⊥ if there is no match), then use unamb to combine them.

The invariant you need to maintain is that potentially overlapping pattern matches (p1 and p2, here) must return the same result.

With a little typeclass hackery you could turn this into

zip = unambPatterns [p1,p2,p3] where {- p1, p2, p3 as above -}

I liked Ryan’s unambPatterns idea very much, and then it occurred me that the necessary “typeclass hackery” is already part of the lub library, as described in the post Merging partial values. The lub operator (“least upper bound”, also written “⊔”), combines information from its arguments and is defined in different ways for different types (via a type class). For functions,

instance HasLub b => HasLub (a -> b) where
  f ⊔ g =  a -> f a ⊔ g a

More succinctly, on functions, (⊔) = liftA2 (⊔).

Using this instance twice gives a (⊔) suitable for curried functions of two arguments, which turns out to give us almost exactly what we want for Ryan’s zip definitions.

zip' = lubs [p1,p2,p3]
 where
   p1 []     _      = []
   p2 _      []     = []
   p3 (x:xs) (y:ys) = (x,y) : zip' xs ys

where

lubs :: [a] -> a
lubs = foldr (⊔) undefined

The difference between zip and zip' shows up in inferred HasLub type constraints on a and b:

zip' :: (HasLub a, HasLub b) => [a] -> [b] -> [(a,b)]

Let’s see if this definition works:

*Data.Lub> zip' [] undefined :: [(Int,Int)]
[]
*Data.Lub> zip' undefined [] :: [(Int,Int)]
[]

Next, an example that requires some recursive calls:

*Data.Lub> zip' [10,20] (1 : 2 : undefined)
[(10,1),(20,2)]
*Data.Lub> zip' (1 : 2 : undefined) [10,20]
[(1,10),(2,20)]

Lazy and bias-free!

If you want to try out out this example, be sure to get at least version 0.1.9 of unamb. I tweaked the implementation to handle pattern-match failures gracefully.

Checking totality

One unfortunate aspect of this definition style is that the Haskell compiler can no longer reliably warn us about non-exhaustive pattern-based definitions. With warnings turned on, I get the following messages:

Warning: Pattern match(es) are non-exhaustive
         In the definition of `p1': Patterns not matched: (_ : _) _

Warning: Pattern match(es) are non-exhaustive
         In the definition of `p2': Patterns not matched: _ (_ : _)

Warning: Pattern match(es) are non-exhaustive
         In the definition of `p3':
             Patterns not matched:
                 [] _
                 (_ : _) []

Perhaps a tool like Neil Mitchell’s Catch could be adapted to understand the semantics of unamb and lub (⊔) sufficiently to prove totality.

More possibilities

The zip' definition above places HasLub constraints on the type parameters a and b. The origin of these constraints is the HasLub instance for pairs, which is roughly the following:

instance (HasLub a, HasLub b) => HasLub (a,b) where
  (a,b) ⊔ (a',b') = (a ⊔ a', b ⊔ b')

This instance is subtly incorrect. See Merging partial values.

Thanks to this instance, each argument to (⊔) can contribute partial information to each half of the pair. (As a special case, each argument could contribute a half.)

Although I haven’t run into a use for this flexibility yet, I’m confident that there are very cool uses waiting to be discovered. Please let me know if you have any ideas.

Last year I stumbled across a simple representation for partial information about values, and wrote about it in two posts, A type for partial values and Implementing a type for partial values. Of particular interest is the ability to combine two partial values into one, combining the information present in each one.

More recently, I played with unambiguous choice, described in the previous post.

This post combines these two ideas. It describes how to work with partial values in Haskell natively, i.e., without using any special representation and without the use restrictions of unambiguous choice. I got inspired to try removing those restrictions during stimulating discussions with Thomas Davie, Russell O’Connor others in the #haskell gang.

You can download and play with the library shown described here. There are links and a bit more info on the lub wiki page.

Edits:

• 2008-11-22: Fixed link: Implementing a type for partial values
• 2008-11-22: Tidied introduction

Information, more or less

The meanings of programming languages are often defined via a technique called “denotational semantics”. In this style, one specifies a mathematical model, or semantic domain, for the meanings of utterances in the and then writes what looks like a recursive functional program that maps from syntax to semantic domain. That “program” defines the semantic function. Really, there’s one domain and one semantic function each syntactic category. In typed languages like Haskell, every type has an associated semantic domain.

One of the clever ideas of the theory of semantic domains (“domain theory”) is to place a partial ordering on values (domain members), based on information content. Values can not only be equal and unequal, they can also have more or less information content than each other. The value with the least information is at the bottom of this ordering, and so is called “bottom”, often written as “⊥”. In Haskell, ⊥ is the meaning of “undefined“. For succinctness below, I’ll write “⊥” instead of “undefined” in Haskell code.

Many types have corresponding flat domains, meaning that the only values are either completely undefined completely defined. For instance, the Haskell type Integer is (semantically) flat. Its values are all either ⊥ or integers.

Structured types are not flat. For instance, the meaning of (i.e., the domain corresponding to) the Haskell type (Bool,Integer) contains five different kinds of values, as shown in the figure. Each arrow leads from a less-defined (less informative) value to a more-defined value.

To handle the diversity of Haskell types, define a class of types for which we know how to compute lubs.

class HasLub a where (⊔) :: a -> a -> a

The actual lub library, uses “lub” instead of “(⊔)“.

The arguments must be consistent, i.e., must have a common upper bound. This precondition is not checked statically or dynamically, so the programmer must take care.

Flat types

For flat types, (⊔) is equivalent to unamb (see Functional concurrency with unambiguous choice), so

-- Flat types:
instance HasLub ()      where (⊔) = unamb
instance HasLub Bool    where (⊔) = unamb
instance HasLub Char    where (⊔) = unamb
instance HasLub Integer where (⊔) = unamb
instance HasLub Float   where (⊔) = unamb
...

Pairs

Too strict

We can handle pairs easily enough:

instance (HasLub a, HasLub b) => HasLub (a,b) where
  (a,b) ⊔ (a',b') = (a ⊔ a', b ⊔ b')

but we’d be wrong! This definition is too strict, e.g.,

(1,2) ⊔ ⊥ == ⊥

when we’d want (1,2).

Too lazy

No problem. Just make the patterns lazy:

instance (HasLub a, HasLub b) => HasLub (a,b) where
  ~(a,b) ⊔ ~(a',b') = (a ⊔ a', b ⊔ b')

Oops — wrong again. This definition is too lazy:

⊥ ⊔ ⊥ == (⊥,⊥)

when we’d want ⊥.

Almost

We can fix the too-lazy version by checking that one of the arguments is non-bottom, which is what seq does. Which one to we check? The one that isn’t ⊥, or either one if they’re both defined. Our friend unamb can manage this task:

instance (HasLub a, HasLub b) => HasLub (a,b) where
  ~p@(a,b) ⊔ ~p'@(a',b') =
    (p `unamb` p') `seq` (a ⊔ a', b ⊔ b')

But there’s a catch (which I realized only now): p and p' may not satisfy the precondition on unamb. (If they did, we could use (⊔) = unamb.)

Just right

To fix this last problem, check whether each pair is defined. We can’t know which to check first, so test concurrently, using unamb.

instance (HasLub a, HasLub b) => HasLub (a,b) where
  ~p@(a,b) ⊔ ~p'@(a',b') =
    (definedP p `unamb` definedP p')
    `seq` (a ⊔ a', b ⊔ b')

where

definedP :: (a,b) -> Bool
definedP (_,_) = True

The implicit second case in that definition is definedP ⊥ = ⊥.

Some examples:

*Data.Lub> (⊥,False) ⊔ (True,⊥)
(True,False)
*Data.Lub> (⊥,(⊥,False)) ⊔ ((),(⊥,⊥)) ⊔ (⊥,(True,⊥))
((),(True,False))

Sums

For sums, we’ll discriminate between lefts and rights, with the following assistants:

isL :: Either a b -> Bool
isL = either (const True) (const False)

outL :: Either a b -> a
outL = either id (error "outL on Right")

outR :: Either a b -> b
outR = either (error "outR on Left") id

The (⊔) method for sums unwraps its arguments as a Left or as a Right, after checking which kind of arguments it gets. We can’t know which one to check first, so check concurrently:

instance (HasLub a, HasLub b) => HasLub (Either a b) where
  s ⊔ s' = if isL s `unamb` isL s' then
             Left  (outL s ⊔ outL s')
           else
             Right (outR s ⊔ outR s')

Functions

A function f is said to be less (or equally) defined than a function g when f is less (or equally) defined g for every argument value. Consequently,

instance HasLub b => HasLub (a -> b) where
  f ⊔ g =  a -> f a ⊔ g a

More succinctly:

instance HasLub b => HasLub (a -> b) where (⊔) = liftA2 (⊔)

Other types

We’ve already handled the unit type (), other flat types, pairs, sums, and functions. Algebraic data types can be modeled via this standard set, with a technique from generic programming. Define methods that map to and from a type in the standard set.

class HasRepr t r | t -> r where
  -- Required: unrepr . repr == id
  repr   :: t -> r  --  to repr
  unrepr :: r -> t  -- from repr

We can implement (⊔) on a type by performing a (⊔) on that type’s standard representation, as follows:

repLub :: (HasRepr a v, HasLub v) => a -> a -> a
a `repLub` a' = unrepr (repr a ⊔ repr a')

instance (HasRepr t v, HasLub v) => HasLub t where
  (⊔) = repLub

However, this rule would overlap with all other HasLub instances, because Haskell instance selection is based only on the head of an instance definition, i.e., the part after the “=>“. Instead, we’ll define a HasLub instance per HasRepr instance.

For instance, here are encodings for Maybe and for lists:

instance HasRepr (Maybe a) (Either () a) where
  repr   Nothing   = (Left ())
  repr   (Just a)  = (Right a)

  unrepr (Left ()) = Nothing
  unrepr (Right a) = (Just a)

instance HasRepr [a] (Either () (a,[a])) where
  repr   []             = (Left  ())
  repr   (a:as)         = (Right (a,as))

  unrepr (Left  ())     = []
  unrepr (Right (a,as)) = (a:as)

And corresponding HasLub instances:

instance HasLub a => HasLub (Maybe a) where (⊔) = repLub
instance HasLub a => HasLub [a]       where (⊔) = repLub

Testing:

*Data.Lub> [1,⊥,2] ⊔ [⊥,3,2]
[1,3,2]