This post is part four of the zip folding series inspired by Max Rabkin’s Beautiful folding post. I meant to write one little post, but one post turned into four. When I sense that something can be made simpler/clearer, I can’t leave it be.

To review:

• Part One related Max’s data representation of left folds to type class morphisms, a pattern that’s been steering me lately toward natural (inevitable) design of libraries.
• Part Two simplified that representation to help get to the essence of zipping, and in doing so lost the expressiveness necessary to define Functorand Applicative instaces.
• Part Three proved the suitability of the zipping definitions in Part Two.

This post shows how to restore the Functor and Applicative (very useful composition tools) to folds but does so in a way that leaves the zipping functionality untouched. This new layer is independent of folding and can be layered onto any zippable type.

You can get the code described below.

What’s missing?

Max’s fold type packages up the first two arguments of foldl' and adds on an post-fold step, as needed for fmap:

data Fold b c = forall a. F (a -> b -> a) a (a -> c)  – clever version

The simpler, less clever version just has the two foldl' arguments, and no forall:

data Fold b a = F (a -> b -> a) a                     – simple version

Removing Max’s post-fold step gets to the essence of fold zipping but loses some useful composability. In particular, we can no longer define Functor and Applicative instances.

The difference between the clever version and the simple one is a continuation and a forall, which we can write down as follows:

data WithCont h b c = forall a. WC (h b a) (a -> c)

The clever version is equivalent to the following:

type FoldC = WithCont Fold

Interpretating a FoldC just interprets the Fold and then applies the continuation:

cfoldlc :: FoldC b a -> [b] -> a
cfoldlc (WC f k) = k . cfoldl f

Add a copy of WithCont, for reasons explained later, and use it for strict folds.

data WithCont’ h b c = forall a. WC’ (h b a) (a -> c)
 
type FoldC’ = WithCont’ Fold
 
cfoldlc’ :: FoldC’ b a -> [b] -> a
cfoldlc’ (WC’ f k) = k . cfoldl’ f

From Zip to Functor and Applicative

It’s now a simple matter to recover the lost Functor and Applicative instances, for both non-strict and strict zipping. The Applicative instances rely on zippability:

instance Functor (WithCont h b) where
  fmap g (WC f k) = WC f (g . k)
 
instance Zip (h b) => Applicative (WithCont h b) where
  pure a = WC undefined (const a)
  WC hf hk <*> WC xf xk =
    WC (hf `zip` xf) (\ (a,a’) -> (hk a) (xk a’))
 
 
instance Functor (WithCont’ h b) where
  fmap g (WC’ f k) = WC’ f (g . k)
 
instance Zip’ (h b) => Applicative (WithCont’ h b) where
  pure a = WC’ undefined (const a)
  WC’ hf hk <*> WC’ xf xk =
    WC’ (hf `zip‘` xf) (\ (P a a’) -> (hk a) (xk a’))

Now the reason for the duplicate WithCont definition becomes apparent. Instance selection in Haskell is based entirely on the “head” of an instance. If both Applicative instances used WithCont, the compiler would consider them to overlap.

Morphism proofs

It remains to prove that our interpretation functions are Functor and Applicative morphisms. I’ll show the non-strict proofs. The strict morphism proofs go through similarly.

Functor

The Functor morphism property for non-strict folding:

cfoldlc (fmap g wc) == fmap g (cfoldlc wc)

Adding some structure:

cfoldlc (fmap g (WC f k)) == fmap g (cfoldlc (WC f k))

Proof:

cfoldlc (fmap g (WC f k))
 
  == {- fmap on WithCont -}
 
cfoldlc (WC f (g . k))
 
  == {- cfoldlc def -}
 
(g . k) . cfoldl f
 
  == {- associativity of (.)  -}
 
g . (k . cfoldl f)
 
  == {- cfoldl def -}
 
g . cfoldlc (WC f k)
 
  == {- fmap on functions -}
 
fmap g (cfoldlc (WC f k))

Applicative

Applicative has two methods, so cfoldlc must satisfy two morphism properties. One for pure:

cfoldlc (pure a) == pure a

Proof:

cfoldlc (pure a)
 
  == {- pure on WithCont -}
 
cfoldlc (WC undefined (const a))
 
  == {- cfoldlc def -}
 
const a . cfoldl undefined
 
  == {- property of const -}
 
const a
 
  == {- pure on functions -}
 
pure a

And one for (<*>):

cfoldlc (wch <*> wcx) == cfoldlc wch <*> cfoldlc wcx

Adding structure:

cfoldlc ((WC hf hk) <*> (WC xf xk)) == cfoldlc (WC hf hk) <*> cfoldlc (WC xf xk)

Proof:

cfoldlc ((WC hf hk) <*> (WC xf xk))
 
  == {- (<*>) on WithCont -}
 
cfoldlc (WC (hf `zip` xf) (\ (a,a’) -> (hk a) (xk a’)))
 
  == {- cfoldlc def -}
 
(\ (a,a’) -> (hk a) (xk a’)) . cfoldl (hf `zip` xf)
 
  == {- Zip morphism law for Fold -}
 
(\ (a,a’) -> (hk a) (xk a’)) . (cfoldl hf `zip` cfoldl xf)
 
  == {- zip def on functions -}
 
(\ (a,a’) -> (hk a) (xk a’)) . \ bs -> (cfoldl hf bs, cfoldl xf bs)
 
  == {- (.) def -}
 
\ bs -> (hk (cfoldl hf bs)) (xk (cfoldl xf bs))
 
  == {- (<*>) on functions -}
 
(hk . cfoldl hf bs) <*> (xk . cfoldl xf)
 
  == {- cfoldlc def, twice -}
 
cfoldlc (WC hf hk) <*> cfoldlc (WC xf xk)

That’s it.

I like that WithCont allows composing the morphism proofs, in addition to the implementations.

The post More beautiful fold zipping showed a formulation of left-fold zipping, simplified from the ideas in Max Rabkin’s Beautiful folding. I claimed that the semantic functions are the inevitable (natural) ones in that they preserve zipping stucture. This post gives the promised proofs.

The correctness of fold zipping can be expressed as follows. Is cfoldl a Zip morphism, and is cfoldl' a Zip' morphism? (See More beautiful fold zipping for definitions of these functions and classes, and see Simplifying semantics with type class morphisms for the notion of type class morphisms.)

Non-strict

The non-strict version is simpler, though less useful. We want to prove

cfoldl (f `zip` f’) == cfoldl f `zip` cfoldl f’

First, substitute the definition of zip for functions.

instance Zip ((->) u) where zip = liftA2 (,)

This definition is a standard one for zipping applicative functors. Given the Applicative instance for functions, this Zip instance is equivalent to

instance Zip ((->) u) where r `zip` s = \ u -> (r u, s u)

So the Zip morphism property becomes

cfoldl (f `zip` f’) bs == (cfoldl f bs, cfoldl f’ bs)

We’ll want some structure to our folds as well:

cfoldl (F op e `zip` F op’ e’) bs
  == (cfoldl (F op e) bs, cfoldl (F op’ e’) bs)

Simplify the LHS:

cfoldl (F op e `zip` F op’ e’) bs
 
  == {- Fold zip def -}
 
cfoldl (F op” (e,e’)) bs
  where (a,a’) `op”` b = (a `op` b, a’ `op’` b)
 
  == {- cfoldl def -}
 
foldl op” (e,e’) bs
  where (a,a’) `op”` b = (a `op` b, a’ `op’` b)

Then simplify the RHS:

(cfoldl (F op e) bs, cfoldl (F op’ e’) bs)
 
  == {- cfoldl def -}
 
(foldl op e bs, foldl op’ e’ bs)

So the morphism law becomes

foldl op” (e,e’) bs == (foldl op e bs, foldl op’ e’ bs)
  where
    (a,a’) `op”` b = (a `op` b, a’ `op’` b)

We’ll prove this form inductively in the list bs, using the definition of foldl:

foldl :: (a -> b -> a) -> a -> [b] -> a
foldl op a []     = a
foldl op a (b:bs) = foldl f (a `op` b) bs

First, empty lists.

foldl op” (e,e’) [] where op” = …
 
  == {- foldl def  -}
 
(e,e’)
 
  == {- foldl def, twice -}
 
(foldl op e [], foldl op’ e’ [])

Next, non-empty lists.

foldl op” (e,e’) (b:bs) where op” = …
 
  == {- foldl def -}
 
foldl op” ((e,e’) `op”` b) bs where op” = …
 
  == {- op” definition -}
 
foldl op” (e `op` b, e’ `op’` b) bs where op” = …
 
  == {- induction hypothesis -}
 
(foldl op (e `op` b) bs, foldl op’ (e’ `op’` b) bs)
 
  == {- foldl def, twice -}
 
(foldl op e (b:bs), foldl op’ e’ (b:bs))

Strict

The morphism law:

cfoldl' (f `zip‘` f’) == cfoldl’ f `zip‘` cfoldl’ f’

which simplifies to

foldl‘ op” (P e e’) bs == P (foldl‘ op e bs) (foldl‘ op’ e’ bs)
  where
    P a a’ `op”` b = P (a `op` b) (a’ `op’` b)

This property can be proved similarly to the non-strict version. The new aspect is manipulating the use of seq.

Again, use induction on lists, guided by the fold definition:

foldl‘ :: (a -> b -> a) -> a -> [b] -> a
foldl‘ op a []     = a
foldl‘ op a (b:bs) =
  let a’ = a `op` b in a’ `seq` foldl‘ f a’ bs

First, empty lists.

foldl op” (P e e’) [] where op” = …
 
  == {- foldl def  -}
 
P e e’
 
  == {- foldl def, twice -}
 
P (foldl op e []) (foldl op’ e’ [])

Next, non-empty lists. For simplicity, I’ll inline the let in the definition of foldl' (which affects performance but not meaning):

foldl‘ op” (P e e’) (b:bs) where op” = …
 
  == {- foldl’ def -}
 
((P e e’) `op”` b) `seq`
foldl‘ op” ((P e e’) `op”` b) bs where op” = …
 
  == {- op” definition -}
 
P (e `op` b) (e’ `op’` b) `seq`
foldl‘ op” (P (e `op` b) (e’ `op’` b)) bs
 
  == {- induction hypothesis -}
 
P (e `op` b) (e’ `op’` b) `seq`
P (foldl‘ op (e `op` b) bs) (foldl‘ op’ (e’ `op` b) bs)
 
  == {- P strictness -}
 
P (e `op` b) (e’ `op’` b) `seq`
P ((e  `op` b) `seq` foldl‘ op  (e  `op` b) bs)
  ((e’ `op` b) `seq` foldl‘ op’ (e’ `op` b) bs)
 
  == {- foldl’ def, twice -}
 
P (foldl‘ op e (b:bs)) (foldl‘ op’ e’ (b:bs))

That’s it.

My previous post, Another lovely example of type class morphisms, placed some standard structure around Max Rabkin’s Beautiful folding, using type class morphisms to confirm that the Functor and Applicative instances agreed with their inevitable meanings.

In the process of working out the Applicative case, I realized the essence of fold zipping was getting a bit obscured. This post simplifies Max’s Fold data type a bit and shows how to zip strict left folds in the simpler setting. You can get the code described here.

Edits:

• 2008-11-15: I renamed the Pair and Pair' classes to Zip and Zip'.

A simpler fold

The strict left-folding functional is

foldl‘ :: (a -> b -> a) -> a -> [b] -> a

Max’s fold type packages up the first two arguments of foldl' and adds on an post-fold step, as needed for fmap:

data Fold b c = forall a. F (a -> b -> a) a (a -> c)  – clever version

A simpler, less clever version just has the two foldl' arguments, and no forall:

data Fold b a = F (a -> b -> a) a  – simple version

I’ll use this simpler version for zipping and later enhance it for fmap.

The strict interpretation of Fold simply unpacks and folds:

cfoldl' :: Fold b a -> [b] -> a
cfoldl’ (F op e) = foldl‘ op e

Zipping is then just a simplification of the (<*>) definition in the previous post. As before, P is a type and constructor of strict pairs.

data P c c’ = P !c !c’
 
zipF’ :: Fold b a -> Fold b a’ -> Fold b (P a a’)
F op e `zipF’` F op’ e’ = F op” (P e e’)
 where
   P a a’ `op”` b = P (a `op` b) (a’ `op’` b)

We can also define non-strict counterparts:

cfoldl :: Fold b a -> [b] -> a
cfoldl (F op e) = foldl op e
 
zipF :: Fold b a -> Fold b a’ -> Fold b (a,a’)
F op e `zipF` F op’ e’ = F op” (e,e’)
 where
   (a,a’) `op”` b = (a `op` b, a’ `op’` b)

More type classes …

A previous post suggested a criterion for inevitability of interpretation functions like cfoldl and cfoldl'. Whatever class instances exists for the source type (Fold here), interpretation functions should be “type class morphisms” for those classes, which loosely means that the meaning of a method is the same method on the meaning.

Where’s the type class for our simplified Fold? It lacks the magic ingredient Max added to make it a Functor and an Applicative, namely the post-fold step.

However, there’s another class that’s just the thing:

class Zip f where zip :: f a -> f b -> f (a,b)

(I’ve used this class with type representations and user interfaces.)

The Zip class from TypeCompose is almost identical to the Zip class in category-extras. The latter class requires Functor, however, which is too restrictive for the simplified Fold type.

Our non-strict left folds have a Zip instance:

instance Zip (Fold b) where zip = zipF

For strict folds, define a strict variant on Zip:

class Zip’ f where zip‘ :: f a -> f b -> f (P a b)

and a Zip' instance for Fold:

instance Zip’ (Fold b) where zip‘ = zipF’

… and more morphisms

These zipping classes have associated morphism properties. A function q mapping from one Zip instance to another is a “Zip morphism” when

q (f `zip` g) == q f `zip` q g

for all folds f and g.

Similarly for Zip' morphisms:

q (f `zip‘` g) == q f `zip‘` q g

In other words, q distributes over zip or zip'.

As I’ll show in another post, the two interpretation functions cfoldl and cfoldl' are Zip and Zip' morphisms, respectively, i.e.,

cfoldl  (f `zip`  g) == cfoldl  f `zip`  cfoldl  g
 
cfoldl’ (f `zip‘` g) == cfoldl’ f `zip‘` cfoldl’ g

which means that zip folding as defined above works correctly.

What’s next?

I like to keep blog posts fairly short, so I’ll share two more pieces of this story in upcoming blog posts:

• Regaining the lost Functor and Applicative instances.
• The Zip and Zip' morphism proofs for zip folding.

I read Max Rabkin’s recent post Beautiful folding with great excitement. He shows how to make combine multiple folds over the same list into a single pass, which can then drastically reduce memory requirements of a lazy functional program. Max’s trick is giving folds a data representation and a way to combine representations that corresponds to combining the folds.

Peeking out from behind Max’s definitions is a lovely pattern I’ve been noticing more and more over the last couple of years, namely type class morphisms.

Folds as data

Max gives a data representation of folds and adds on an post-fold step, which makes them composable.

data Fold b c = forall a. F (a -> b -> a) a (a -> c)

The components of a Fold are a (strict left) fold’s combiner function and initial value, plus a post-fold step. This interpretation is done by a function cfoldl', which turns these data folds into function folds:

cfoldl' :: Fold b c -> [b] -> c
cfoldl’ (F op e k) = k . foldl‘ op e

where foldl' is the standard strict, left-fold functional:

foldl‘ :: (a -> b -> a) -> a -> [b] -> a
foldl‘ op a []     = a
foldl‘ op a (b:bs) =
  let a’ = a `op` b in a’ `seq` foldl‘ f a’ bs

Standard classes

As Twan van Laarhoven pointed out in a comment on Max’s post, Fold b is a functor and an applicative functor, so some of Max’s Fold-manipulating functions can be replaced by standard vocabulary.

The Functor instance is pretty simple:

instance Functor (Fold b) where
  fmap h (F op e k) = F op e (h . k)

The Applicative instance is a bit trickier. For strictness, Max used used a type of strict pairs:

data Pair c c’ = P !c !c’

The instance:

instance Applicative (Fold b) where
  pure a = F (error "no op") (error "no e") (const a)
 
  F op e k <*> F op’ e’ k’ = F op” e” k”
   where
     P a a’ `op”` b = P (a `op` b) (a’ `op’` b)
     e”             = P e e’
     k” (P a a’)    = (k a) (k’ a’)

Given that Fold b is an applicative functor, Max’s bothWith function is then liftA2. Max’s multi-cfoldl' rule then becomes:

forall c f g xs.
   h (cfoldl’ f xs) (cfoldl’ g xs) == cfoldl’ (liftA2 h f g) xs

thus replacing two passes with one pass.

Beautiful properties

Now here’s the fun part. Looking at the Applicative instance for ((->) a), the rule above is equivalent to

forall c f g.
  liftA2 h (cfoldl’ f) (cfoldl’ g) == cfoldl’ (liftA2 h f g)

Flipped around, this rule says that liftA2 distributes over cfoldl'. Or, “the meaning of liftA2 is liftA2“. Neat, huh?

Moreover, this liftA2 property is equivalent to the following:

forall f g.
  cfoldl’ f <*> cfoldl’ g == cfoldl’ (f <*> g)

This form is one of the two Applicative morphism laws (which I usually write in the reverse direction):

For more about these morphisms, see Simplifying semantics with type class morphisms. That post suggests that semantic functions in particular ought to be type class morphisms (and if not, then you’d have an abstraction leak). And cfoldl' is a semantic function, in that it gives meaning to a Fold.

The other type class morphisms in this case are

cfoldl' (pure a  ) == pure a
 
cfoldl’ (fmap h f) == fmap h (cfoldl’ f)

Given the Functor and Applicative instances of ((->) a), these two properties are equivalent to

cfoldl' (pure a  ) == const a
 
cfoldl’ (fmap h f) == h . cfoldl’ f

or

cfoldl' (pure a  ) xs == a
 
cfoldl’ (fmap h f) xs == h (cfoldl’ f xs)

Rewrite rules

Max pointed out that GHC does not handle his original multi-cfoldl' rule. The reason is that the head of the LHS (left-hand side) is a variable. However, the type class morphism laws have constant (known) functions at the head, so I expect they could usefully act as fusion rewrite rules.

Inevitable instances

Given the implementations (instances) of Functor and Applicative for Fold, I’d like to verify that the morphism laws for cfoldl' (above) hold.

Functor

Start with fmap. The morphism law:

cfoldl' (fmap h f) == fmap h (cfoldl’ f)

First, give the Fold argument more structure, so that (without loss of generality) the law becomes

cfoldl' (fmap h (F op e k)) == fmap h (cfoldl’ (F op e k))

The game is to work backward from this law to the definition of fmap for Fold. I’ll do so by massaging the RHS (right-hand side) into the form cfoldl' (...), where “...” is the definition fmap h (F op e k).

fmap h (cfoldl’ (F op e k))
 
  ==  {- inline cfoldl’ -}
 
fmap h (k . foldl‘ op e)
 
  ==  {- inline fmap on functions -}
 
h . (k . foldl‘ op e)
 
  ==  {- associativity of (.) -}
 
(h . k) . foldl‘ op e
 
  ==  {- uninline cfoldl’ -}
 
cfoldl’ (F op e (h . k))
 
  ==  {- uninline fmap on Fold  -}
 
cfoldl’ (fmap h (F op e k))

This proof show why Max had to add the post-fold function k to his Fold type. If k weren’t there, we couldn’t have buried the h in it.

More usefully, this proof suggests how we could have discovered the fmap definition. For instance, we might have tried with a simpler and more obvious Fold representation:

data FoldS a b = FS (a -> b -> a) a

Getting into the fmap derivation, we’d come to

h . foldsl' op e

and then we’d be stuck. But not really, because the awkward extra bit (h .) beckons us to generalize by adding Max’s post-fold function.

Applicative

Next pure:

cfoldl' (pure a) == pure a

Reason as before, starting with the RHS

pure a
 
  ==  {- inline pure on functions -}
 
const a
 
  ==  {- property of const -}
 
const a . foldl op e
 
  ==  {- uninline cfoldl’ -}
 
cfoldl’ (F (const a) op e)

The imaginative step was inventing structure to match the definition of cfoldl'. This definition is true for any values of op and e, so we can use bottom in the definition:

instance Applicative (Fold b) where
  pure a = F undefined undefined (const a)

As Twan noticed, the existential (forall) also lets us pick defined values for op and e. He chose (\_ _ -> ()) and ().

The derivation of (<*>) is trickier and is the heart of the problem of fusing folds to reduce multiple traversals to a single one. Why the heart? Because (<*>) is all about combining two things into one.

Intermission

I’m taking a break here. While fiddling with a proof of the (<*>) morphism law, I realized a simpler way to structure these folds, which will be the topic of an upcoming post.

A previous post described a data type of functional linear maps. As Andy Gill pointed out, we had a heck of a time trying to get good performance. This note describes a new representation that is very simple and much more efficient. It’s terribly obvious in retrospect but took me a good while to stumble onto.

The Haskell module described here is part of the vector-space library (version 0.5 or later) and requires ghc version 6.10 or better (for associated types).

Edits:

• 2008-11-09: Changed remarks about versions. The vector-space version 0.5 depends on ghc 6.10.
• 2008-10-21: Fixed the vector-space library link in the teaser.

Linear maps

Semantically, a linear map is a function f :: a -> b such that, for all scalar values s and “vectors” u, v :: a, the following properties hold:

By repeated application of these properties,

Taking the u_i as basis vectors, this form implies that a linear function is determined by its behavior on any basis of its domain type.

Therefore, a linear function can be represented simply as a function from a basis, using the representation described in Vector space bases via type families.

type u :-* v = Basis u -> v

The semantic function converts from (u :-* v) to (u -> v). It decomposes a source vector into its coordinates, applies the basis function to basis representations, and linearly combines the results.

lapply :: ( VectorSpace u, VectorSpace v
          , Scalar u ~ Scalar v, HasBasis u ) =>
          (u :-* v) -> (u -> v)
lapply lm = \ u -> sumV [s *^ lm b | (b,s) <- decompose u]

or

lapply lm = linearCombo . fmap (first lm) . decompose

The reverse function is easier. Convert a function f, presumed linear, to a linear map representation:

linear :: (VectorSpace u, VectorSpace v, HasBasis u) =>
          (u -> v) -> (u :-* v)

It suffices to apply f to basis values:

linear f = f . basisValue

Memoization

The idea of the linear map representation is to reconstruct an entire (linear) function out of just a few samples. In other words, we can make a very small sampling of function’s domain, and re-use those values in order to compute the function’s value at all domain values. As implemented above, however, this trick makes function application more expensive, not less. If lm = linear f, then each use of lapply lm can apply f to the value of every basis element, and then linearly combine results.

A simple trick fixes this efficiency problem: memoize the linear map. We could do the memoization privately, e.g.,

linear f = memo (f . basisValue)

If lm = linear f, then no matter how many times lapply lm is applied, the function f can only get applied as many times as the dimension of the domain of f.

However, there are several other ways to make linear maps, and it would be easy to forget to memoize each combining form. So, instead of the function representation above, I ensure that the function be memoized by representing it as a memo trie.

type u :-* v = Basis u :->: v

The conversion functions linear and lapply need just a little tweaking. Split memo into its definition untrie . trie, and then move the second phase (untrie) into lapply. We’ll also have to add HasTrie constraints:

linear :: ( VectorSpace u, VectorSpace v
          , HasBasis u, HasTrie (Basis u) ) =>
          (u -> v) -> (u :-* v)
linear f = trie (f . basisValue)
 
lapply :: ( VectorSpace u, VectorSpace v, Scalar u ~ Scalar v
          , HasBasis u, HasTrie (Basis u) ) =>
          (u :-* v) -> (u -> v)
lapply lm = linearCombo . fmap (first (untrie lm)) . decompose

Now we can build up linear maps conveniently and efficiently by using the operations on memo tries shown in Composing memo tries. For instance, suppose that h is a linear function of two arguments (linear in both, not it each) and m and n are two linear maps. Then liftA2 h m n is the linear function that applies h to the results of m and n.

lapply (liftA2 h m n) a = h (lapply m a) (lapply n a)

Exploting the applicative functor instance for functions, we get another formulation:

lapply (liftA2 h m n) = liftA2 h (lapply m) (lapply n)

In other words, the meaning of a liftA2 is the liftA2 of the meanings, as discussed in Simplifying semantics with type class morphisms.

A basis B of a vector space V is a subset B of V, such that the elements of B are linearly independent and span V. That is to say, every element (vector) of V is a linear combination of elements of B, and no element of B is a linear combination of the other elements of B. Moreover, every basis determines a unique decomposition of any member of V into coordinates relative to B.

This post gives a simple Haskell implementation for a canonical basis of a vector space, and a means of decomposing vectors into coordinates. It uses indexed type families (associated types), and is quite general, despite its simplicity.

The Haskell module described here is part of the vector-space library (version 0.4 or later), which available on Hackage and a darcs repository. See the wiki page, interface documentation, and source code. The library version described below (0.5 or later) relies on ghc 6.10.

Edits:

• 2008-11-09: Tweaked comment above about version.
• 2008-02-09: just fiddling around

Additive groups and vector spaces

We’ll need a bit of preliminary before jumping into basis types.

An additive group has addition operation, with an identity (zero) and an additive inverse:

class AdditiveGroup v where
  (^+^)   :: v -> v -> v
  zeroV   :: v
  negateV :: v -> v

A vector space is an additive group with scalar multiplication, so it also has an associated type of scalars:

class AdditiveGroup v => VectorSpace v where
  type Scalar v :: *
  (*^) :: Scalar v -> v -> v

This associated type could instead by written as a functional dependency (fundep). In fact, the type family implementation in ghc 6.9 is not quite up to working with the code in this post, so the library contains a (6.9-friendly) version together with as a fundep (Data.VectorSpace) and the version given in this post (Data.AVectorSpace). Sometime after ghc-6.10 is released, I will retire the fundep version and rename AVectorSpace to VectorSpace. Similarly, the library temporarily contains Data.ABasis.

Basis types

Since Haskell doesn’t have subtyping, we can’t represent a basis type directly as a subset. Instead, for an arbitrary vector space v, represent the (canonical) basis as an associated type, Basis v, and a function that interprets a basis representation as a vector.

class VectorSpace v => HasBasis v where
  type Basis v :: *
  basisValue   :: Basis v -> v

Another method extracts coordinates (coefficients) for a vector. Each coordinate is associated with a basis element.

  decompose    :: v -> [(Basis v, Scalar v)]

We can also reverse the process, recomposing into a vector, by linearly combining the basis elements:

linearCombo :: VectorSpace v => [(v,Scalar v)] -> v
linearCombo ps = sumV [s *^ v | (v,s) <- ps]
 
recompose :: HasBasis v => [(Basis v, Scalar v)] -> v
recompose = linearCombo . fmap (first basisValue)

The defining property is

recompose . decompose == id

Exercise: why might decompose . recompose not be the identity? What if the decomposition were represented instead as a finite map?

Primitive bases

Any scalar field is also a vector space over itself. For instance,

instance AdditiveGroup Double where
  zeroV   = 0.0
  (^+^)   = (+)
  negateV = negate
 
instance VectorSpace Double where
  type Scalar Double = Double
  (*^) = (*)

The canonical basis of a one-dimensional space has only one element, namely 1, which can be represented with no information.

instance HasBasis Double where
  type Basis Double = ()
  basisValue ()     = 1
  decompose s       = [((),s)]

Composing bases

Pairs of additive groups form additive groups:

instance (AdditiveGroup u,AdditiveGroup v)
      => AdditiveGroup (u,v) where
  zeroV             = (zeroV,zeroV)
  (u,v) ^+^ (u’,v’) = (u^+^u’,v^+^v’)
  negateV (u,v)     = (negateV u,negateV v)

Pairs of vector spaces, over the same scalar field, form vector spaces:

instance (VectorSpace u,VectorSpace v, Scalar u ~ Scalar v)
      => VectorSpace (u,v) where
  type Scalar (u,v) = Scalar u
  s *^ (u,v) = (s*^u,s*^v)

Given vector spaces u and v, a basis representation for (u,v) will be one basis representation or the other, tagged with Left or Right:

instance (HasBasis u, HasBasis v, Scalar u ~ Scalar v)
      => HasBasis (u,v) where
  type Basis (u,v) = Basis u `Either` Basis v

The basis vectors themselves will be (ub,0) or (0,vb), where ub is a basis vector for u, and vb is a basis vector for v. As expected then, the dimensionality of the cross product is the sum of the dimensions.

  basisValue (Left  a) = (basisValue a, zeroV)
  basisValue (Right b) = (zeroV, basisValue b)

The decomposition of a vector (u,v) contains left-tagged decompositions of u and right-tagged decompositions of v.

  decompose (u,v) = decomp2 Left u ++ decomp2 Right v

where

decomp2 :: HasBasis w => (Basis w -> b) -> w -> [(Scalar w, b)]
decomp2 inject = fmap (first inject) . decompose

Triples etc, can be handled similarly. Instead, the library implementation reduces them to the pair case:

instance ( HasBasis u, s ~ Scalar u
         , HasBasis v, s ~ Scalar v
         , HasBasis w, s ~ Scalar w )
      => HasBasis (u,v,w) where
  type Basis (u,v,w) = Basis (u,(v,w))
  …

Exercise: complete this instance definition (without peeking).

Bases in spaces

What about other vector spaces, particularly infinite dimensional ones? The result type for decompose is not convenient:

decompose :: v -> [(Basis v, Scalar v)]

Moreover, its definition for pair types would have to be changed, e.g., to use interleaving instead of append. On the other hand, this type can be thought of as an association list, representing Basis v -> Scalar v. Instead, we might use the function representation directly:

decompose :: v -> (Basis v -> Scalar v)

In that case, the definition of decompose on pairs is

decompose (u,v) = decompose u `either` decompose v

which beautifully mirrors the basis type definition:

type Basis (u,v) = Basis u `Either` Basis v

I guess we’d have to somehow extend the definition of recompose as well, or avoid it.

One example of an infinite dimensional vector space is a function over an infinite domain. The additive group and vector space instances follow a standard form for applicative functors applied to an additive group or vector space. In this case, the applicative functor is ((->) a).

instance AdditiveGroup v => AdditiveGroup (a -> v) where
  zeroV   = pure   zeroV
  (^+^)   = liftA2 (^+^)
  negateV = fmap   negateV
 
instance VectorSpace v => VectorSpace (a -> v) where
  type Scalar (a -> v) = Scalar v
  (*^) s = fmap ((*^) s)

As a basis for a function space a->u, let’s use the subset of functions that map one domain value to some basis vector for u and map all other domain values to zero. By linearly combining these functions, we can construct any function in a->u that is nonzero for finitely many domain values. If we stretch the notion of linear combinations beyond finite combinations, perhaps we can go further and cover at least the countably infinite domain types.

To represent these functions, it suffices to record the choice of domain element and the representation of the corresponding basis vector for u:

instance (Eq a, HasBasis u) => HasBasis (a -> u) where
  type Basis (a -> u) = (a, Basis u)
 
  basisValue (a,b) a’ | a == a’   = basisValue b
                      | otherwise = zeroV

The actual implementation is a bit more efficient, avoiding recomputation of basisValue b for each a'.

Decomposing a function into its coordinates is even simpler:

  decompose g (a,b) = decompose (g a) b

Some isomorphisms

This instance rule for functions will be applied repeatedly for curried functions. For instance, Basis (a -> b -> u) == (a, (b, Basis u)). The isomorphic uncurried form has an isomorphic basis: Basis ((a,b) -> u) == ((a,b), Basis u).

Pairing in the range instead of domain gives rise to another pair of isomorphisms:

Basis (a -> (b,c)) == (a, Basis b `Either` Basis c)
 
Basis ((a -> b, a -> c)) == (a, Basis b) `Either` (a, Basis c)

The rules for basis types look like logarithms, especially if we add a basis for ():

  type Basis () = Void
 
  type Basis (u,v) = Basis u `Either` Basis v
 
  type Basis (a -> u) = (a, Basis u)

Compare with:

The rules are also essentially the same as the ones used for memo tries, but phrased in terms of logarithms instead of (explicit) exponents.

The post Elegant memoization with functional memo tries showed a simple type of search tries and their use for functional memoization of functions. This post provides some composition tools for memo tries, whose definitions are inevitable, in that they are determined by the principle presented in Simplifying semantics with type class morphisms.

Compositional semantics and type class morphisms

The discipline of denotational semantics defines meaning functions compositionally, i.e., the meaning of a construct must be some function of the meanings of its components.

Type class morphisms make the denotational discipline even more specific:

The meaning of each method corresponds to the same method for the meaning.

For instance,

meaning (a `mappend` b) == meaning a `mappend` meaning b

Memo tries, semantics, and morphisms

The semantic function for a memo trie is untrie, which converts a trie (back) to a function:

untrie :: (a :->: b) -> (a  ->  b)

Let’s look at the consequences of requiring that untrie be a morphism over Monoid, Functor, Applicative, Monad, Category, and Arrow, i.e.,

untrie mempty          == mempty
untrie (s `mappend` t) == untrie s `mappend` untrie t
 
untrie (fmap f t)      == fmap f (untrie t)
 
untrie (pure a)        == pure a
untrie (tf <*> tx)     == untrie tf <*> untrie tx
 
untrie (