This post describes a simple way to integrate a function over an interval and get an exact answer. The question came out of another one, which is how to optimally render a continuous-space image onto a discrete array of pixels.

For anti-aliasing, I’ll make two simplying assumptions (to be revisited):

• Each pixel is a square area. (With apologies to Alvy Ray Smith.)
• Since I can choose only one color per pixel, I want exactly the average of the continuous image over pixel’s subregion of 2D space.

The average of a function over a region (here a continuous image over a 2D interval) is equal to the integral of the function across the region divided by the size (area for 2D) of the region. Since our regions are simple squares, the average and the integral can each be defined easily in terms of the other (dividing or multiplying by the size).

To simplify the problem further, I’ll consider one-dimensional integration, i.e., integrating a function of R over a 1D interval. My solution below involves the least upper bound operator I’ve written about (and its specialization unamb).

A first simple algorithm

Integration takes a real-valued function and an interval (low & high) and gives a real.

integral :: (R->R) -> R -> R -> R

Integration has a property of interval additivity, i.e., the integral of a function from a to c is the sum of the integral from a to b and the integral from b to c.

∀ a b c. integral f a c == integral f a b + integral f b c

which immediately leads to a simple recursive algorithm:

integral f low high = integral f low mid + integral f mid high
  where mid = (low + high) / 2

Extending to 2D is simple: we could divide a rectangular region into four quarter subregions, or into two subregions by splitting the longer dimension. The quartering variation is very like mipmapping, as used to anti-alias textures. Mipmapping takes a pixel array and builds a pyramid of successively lower resolution versions. Each level except the first is constructed out of the previous (next higher-resolution) level by averaging blocks of four pixels into one. The simple integral algorithm above (extended to 2D) is like mipmapping when we start with an infinite resolution (i.e., continuous) texture.

Umm …

Maybe you’re thinking what I’m thinking: Hey! We don’t have a base case, so we won’t even get off the ground.

Given that our domain is continuous, I don’t know what to use for a base case. So let’s consider what the purpose of a base case is, and see whether that purpose can be accomplished some other way.

What’s so important about base cases?

Does every recursion need a base case in order to avoid being completely undefined?

Here’s a counter-example: mapping a function over an infinite stream, taken from the source code of the Stream package.

data Stream a = Cons a (Stream a)

instance Functor Stream where
  fmap f ~(Cons x xs) = Cons (f x) (fmap f xs)

The key thing here is that Cons is non-strict in its second argument, which holds the recursive call. (Definition: a function f is “strict” if f ⊥ == ⊥.)

Non-strictness of if-then-else is exactly what allows more mundane recursions to produce defined (non-⊥) results as well, e.g.,

fac n = if n <= 0 then 1 else fac (n-1)

In this fac example, if-then-else must be (and is) non-strict in its third argument (the recursive call).

So “base case” is not the heart of the matter; non-strictness is.

Finding non-strictness

The trouble with our elegant recursive derivation of integral above is that addition is strict in its arguments (where the recursive integral calls appear). This strictness means that we cannot get any information at all out of the right-hand side until we get some information out of the recursive calls, which won’t happen until we get information out of their recursive calls, ad infinitum.

To escape this information black hole, can we find some scrap of information about the value of the integral that doesn’t (always) rely on the recursive calls?

Interval analysis (IA) provides an answer. The idea of IA is to extend functions to apply to intervals of values and produce intervals of results. The interval versions are sloppy in that a result interval may hold values not corresponding to anything in the source interval. (In math-speak, a result interval may be a proper superset of the image of the source interval under the function.)

Applying an interval version of the function to the source interval results in lower and upper bounds for f. The average must be between these bounds, so the integral is bounded by these bounds multiplied by the interval size. (Or use more sophisticated variations on IA, such as affine analysis, etc.)

Now we have some information. How can we mix it in with the sum of recursive calls to integral? We can use (⊔) (least upper bound or “lub”), which is perfect for the job because its meaning is exactly to combine two pieces of information. See Merging partial values and Lazier function definitions by merging partial values.

Instead of treating IA as operating on intervals, think of it as operating on “partial numbers”, i.e., inexact values. Suppose we define a type of numbers that consistently generalizes exact numbers but is additionally populated with inexact values.

type Partial R  -- abstract

between :: Ord a => a -> a -> Partial a
exact   :: a -> Partial a

Perhaps exact a = between a a.

Now we can escape the black hole:

integral f low high = ((high - low) * f (between low high)) ⊔
                      (integral f low mid + integral f mid high)
  where mid = (low + high) / 2

Representation

One representation of a partial value is an interval. In this representation, (⊔) is interval intersection.

type Partial a = (a,a)  -- first try

(l,h) ⊔ (l',h') = (l `max` l', h `min` h')

If the lower and upper bounds are plain old exact numbers, then this choice of representation and (⊔) has a fatal flaw. The max and min functions are strict, so (⊔) can easily produce less information than it is given, while its job is to combine all information present in both arguments. (For instance, let l == 3 and l' == ⊥. Then l `max` l' == ⊥, so we’ve lost the information from l.)

One possible solution is to change the kind of numbers used in the bounds in such a way that max and min are not strict. Let’s use two new types, for lower and upper bounds:

type Lower a  -- abstract
type Upper a  -- abstract

These two types also capture partial information about numbers, though they cannot express exact numbers (other than maxBound and minBound, where available).

Now we can represent partial numbers.

type Partial a = (Lower a, Upper a)

(l,h) ⊔ (l',h') = (l ⊔ l', h ⊔ h')

Notice that I’ve replaced both max and min each by (⊔). Now I realize that I only used max and min above as a way of combining the information that the lower and upper bounds (respectively) gave us. The (⊔) operator states this intention directly.

Pleasantly, we don’t even have to state this definition, as (⊔) is already defined this way for pairs. (Well, not quite; see Merging partial values.)

Improving values and intervals

This idea for representing partial values is very like what Warren Burton and Ken Jackson called “improving intervals”, which is a two-sided version of Warren’s “improving values” (corresponding to Lower above). (See Encapsulating nondeterminacy in an abstract data type with deterministic semantics (JFP, 1991) and Improving Intervals (JFP, 1993). As these papers are hard to find, you might start with Ken Jackson’s dissertation.)

Warren and Ken represented improving values and intervals as lazy, possibly-infinite lists of improving approximations. While an improving value is represented as a sequence (finite or infinite) of monotonically increasing values, an improving interval is represented as a sequence of monotonically shrinking intervals (each containing the next). The denotation of one of these improving representations is the limit of the sequence. Any query for information not specifically present in a partial value would yield ⊥, just as applying a partial function (or data structure) outside its domain yields ⊥. For instance, one could ask a partial number for successive bits. If a requested bit cannot be determined from the available bounds, then that bit and all later bits are ⊥.

Dropping lub

There’s a subtlety in the second definition of integral above. My goal is that integral yield a completely defined (exact) number. We can meet this goal for fairly well-behaved functions, since IA gives decreasing errors as input intervals shrink, and the result intervals are multiplied by shrinking interval sizes. Even discontinuities in the integrated function will be smoothed out, if there are only finitely many, thanks to the multiplication.

Completely defined values are at the tops of the information ordering. (I’m assuming we don’t have the “over-defined” (self-contradictory) value ⊤.) The sum of recursive calls is also fully defined, and starter partial value, f (between low high), has strictly less information, i.e.,

   (high - low) * f (between low high)
⊑  integral f low high
=  integral f low mid + integral f mid high

So we can get by with a less general form of (⊔). If we represent our numbers as lazy lists of improving intervals, then we can simply use (:) in place of (⊔).

Hm. My reasoning just above is muddled. I think the crucial property is that

     (high - low) * f (between low high)
⊑    (mid  - low) * f (between low mid )
   + (high - mid) * f (between mid high)

To see why this property holds, first subdivide:

     (high - low) * f (between low high)
==   ((mid - low) + (high - mid)) * f (between low high)
==   (mid  - low) * f (between low high)
   + (high - mid) * f (between low high)

Next apply information monotonicity, i.e., more information (smaller interval) in yields more information out:

f (between low high) ⊑ f (between low med)

f (between low high) ⊑ f (between med high)

from which the crucial property follows.

Note: the notation is potentially confusing, since smaller intervals means more information, and so (⊑) means (⊇), and (⊔) means (∩).

Efficiency and benign side-effects

There is a serious efficiency problem with this (lazy) list-based representation of improving values or intervals, as pointed out by Ken and Warren:

At any point in time, it is really only the tightest bounds currently in the list that are important. […] Hence, the list representation consumes more space than is necessary, and time is wasted examining the out-of-date values in the list. A better representation, in a language that allows update-in-place, would be a pair consisting of the tightest lower bound and the tightest upper bound found so far. This pair would be updated-in-place when better bounds become known. (Improving Intervals, section 5.2)

The update-in-place suggested here is semantically benign, i.e., does not compromise pure functional semantics, because it doesn’t change the information content. Instead, it makes that content more efficient to access a second time. The same sort of semantically benign optimization underlies lazy evaluation, with the run-time system destructively replacing a thunk upon its first evaluation.

This benign-update idea is also explored in Another angle on functional future values.

Averaging vs integration

In practice, I’d probably rather use a recursive interval average function instead of a recursive integral. Recall that with the recursive integral, we had to multiply by the interval size at each step. The intervals get very small, and I worry about having to combine numbers of greatly differing magnitudes. With a recursive average, the numbers get averaged at each step, which I expect means we’ll be combining numbers of similar magnitudes.

average f low high = f (between low high) ⊔
                     average f low mid `avg` average f mid high
  where mid = low `avg` high

a `avg` b = (a + b) / 2

integral f low high = (high - low) * average f low high   -- non-recursive

Here’s a modified form that can apply to higher dimensions as well:

average f iv = f iv ⊔ mean [average f iv' | iv' <- subdivide iv]

mean l = sum l / length l

integral f iv = size iv * average f iv   -- non-recursive

Exact computation

The algorithms described above can easily run afoul of inexact numeric representations, such as Float or Double. With such representation types, as recursive subdivision progresses, at some point, an interval will be bounded by consecutive representable numbers. At that point, sub-dividing an interval will result in an empty interval plus the pre-divided interval, and we will stop making progress.

One solution to this problem is use exact number representations. Another is to use progressively precise inexact representations.

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]

In my previous post, I gave an interface for a type of partial values and invited implementations. Here’s mine, which surprised me in its simplicity.

The trick is to represent Partial a as a -> a, i.e., a way to selectively replace parts of a value. Typically the replaced parts are bottom/undefined. I want Partial a to be a monoid, and Data.Monoid provides an instance:

-- | The monoid of endomorphisms under composition.
newtype Endo a = Endo { appEndo :: a -> a }

instance Monoid (Endo a) where
  mempty = Endo id
  Endo f `mappend` Endo g = Endo (f . g)

So my definition is simply a synonym:

type Partial = Endo

Note that mempty and mappend do exactly what I want. mempty adds no information at all, while u `mappend` v adds (overrides) information with u and then with v.

The implementation of functions on Partial is trivial.

inPartial :: ((a->a) -> (a'->a')) -> (Partial a -> Partial a')
inPartial f = Endo . f . appEndo

valp :: c -> Partial c
valp c = Endo (const c)

pval :: Partial c -> c
pval (Endo f) = f undefined
unFst :: Partial a -> Partial (a,b)
unFst = inPartial first

unSnd :: Partial b -> Partial (a,b)
unSnd = inPartial second

unElt :: Functor f => Partial a -> Partial (f a)
unElt = inPartial fmap

I’m not sure I’ll end up using the Partial type in Eros, but I like having it around. If you think of variations, extensions and/or other uses, please let me know.

In simplifying my Eros implementation, I came across a use for a type that represents partial information about values. I came up with a very simple implementation, though perhaps not quite ideal. In this post, I’ll present the interface and invite ideas for implementation. In the next post, I’ll give the implementation I use.

First the type:

type Partial a

I require that Partial a be a monoid, for which mempty is the completely undefined value, and in u `mappend` v, v selectively replaces parts of u. (Lattice-wise, mempty is bottom, and mappend is not quite lub, as it lacks commutativity).

Now the programming interface:

-- Treat a full value as a partial one.  Fully overrides any "previous" (earlier
-- argument to mappend) partial value.
valp :: c -> Partial c

-- Force a partial value into a full one, filling in bottom for any missing parts.
pval :: Partial c -> c

-- Inverse to fst, on partial values.  Inject info into the the first half of a pair,
-- and leave the second half alone.
unFst :: Partial a -> Partial (a,b)

-- Inverse to snd.
unSnd :: Partial b -> Partial (a,b)

-- Inverse to "element" access, on all elements.  A way to inject some info about every
-- element.  For f, consider [], (->) a, Event, etc.
unElt :: Functor f => Partial a -> Partial (f a)

That’s it. I’d love to hear ideas for representing Partial a and implementing the functions above. In the next post, I’ll give mine.