Infinite trees

In the post Memoizing polymorphic functions via unmemoization, I played with a number of container types, looking at which ones are tries over what domain types. I referred to these domain types as "index types" for the container type. One such container was a type of infinite binary trees with values at every node:

data BinTree a = BinTree a (BinTree a) (BinTree a)

By the usual exponent laws, this BinTree functor is (isomorphic to) the functor of tries over a type of binary natural numbers formulated as follows:

data BinNat = Zero | Even BinNat | Odd BinNat

As a variation on this BinTree, we can replace the two subtrees with a pair of subtrees:

data BinTree a = BinTree a (Pair (BinTree a))

Where Pair could be defined as

data Pair a = Pair a a

or, using functor combinators,

type Pair = Id × Id

The reformulation of BinTree leads to a slightly different representation for our index type, a little-endian list of bits:

data BinNat = Zero | NonZero Bool BinNat

or simply

type BinNat = [Bool]

Note that Bool is the index type for Pair (and conversely, Pair is the trie for Bool), which suggests that we play this same trick for all index types and their corresponding trie functors. Generalizing,

data Tree d a = Tree a (d ↛ Tree d a)

where k ↛ v is short for Trie k v, and Trie k is the trie functor associated with the type k. See Elegant memoization with higher-order types.

These generalized trees are indexed by little-endian natural numbers over a "digit" type d:

Tree d a ≅ [d] → a

which is to say that Tree d is a trie for [d]. See Memoizing polymorphic functions via unmemoization for a derivation.

Note that all of these number representations have a serious problem, which is that they distinguish between number representations that differ only by leading zeros. The size-typed versions do not have this problem.

Finite trees

The reason I chose infinite trees was that the finite tree types I knew of have choice-points/alternatives, and so are isomorphic to sums. I don't know of trie-construction techniques that synthesize sums.

Can we design a tree type that is both finite and choice-free? We've already tackled a similar challenge above with lists earlier in previous posts.

In Fixing lists, I wanted to "fix" lists, in the sense of eliminating the choice points in the standard type [a] so that the result could be a trie. Doing so led to the type Vec n a, which appears to have choice points, due to the two constructors ZVec and (:<), but for any given n, at most one constructor is applicable. (For this reason, regular algebraic data types are inadequate.) For handy review,

data Vec ∷ * → * → * where
  ZVec ∷                Vec Z     a
  (:<) ∷ a → Vec n a → Vec (S n) a

Let's try the same trick with trees, fixing depth instead length, to get depth-typed binary trees:

data BinTree ∷ * → * → * where
  Leaf   ∷ a                         → BinTree Z     a
  Branch ∷ BinTree n a → BinTree n a → BinTree (S n) a

Again, we can replace the two subtrees with a single pair of subtrees in the Branch constructor::

  Branch ∷ Pair (BinTree n) a → BinTree (S n) a

Or, recalling that Bool is the index type for Pair:

data BinTree ∷ * → * → * where
  Leaf   ∷                    a → BinTree Z     a
  Branch ∷ (Bool ↛ BinTree n a) → BinTree (S n) a

The use of Bool is rather ad hoc. Its useful property is isomorphism with 1 + 1, whose corresponding trie functor is Id + Id, i.e., Pair. In the post Type-bounded numbers, we saw another, more systematic, type isomorphic to 1 + 1, which is BNat TwoT (i.e., BNat (S (S Z))), which is the type of natural numbers less than two.

  Branch ∷ (BNat TwoT ↛ BinTree n a) → BinTree (S n) a

This replacement suggests a generalization from binary trees to b-ary trees (i.e., having branch factor b).

data VecTree ∷ * → * → * → * where
  Leaf   ∷                        a → VecTree b Z     a
  Branch ∷ (BNat b ↛ VecTree b n a) → VecTree b (S n) a

Recall that the motivation for BNat b was as an index type for Vec b, which is to say that Vec b turned out to be the trie functor for the type BNat b. With this relationship in mind, the Branch type is equivalent to

  Branch ∷ Vec b (VecTree b n a) → VecTree b (S n) a

Unsurprisingly then, a b-ary tree is either a single leaf value or a branch node containing b subtrees. Also, the depth of a leaf is zero, and the depth of a branch node containing b subtrees each of of depth n is n + 1.

We can also generalize this VecTree type by replacing Vec b with an arbitrary functor f:

data FTree ∷ (* → *) → * → * → * where
  Leaf   ∷               a → FTree f Z     a
  Branch ∷ f (FTree f n) a → FTree f (S n) a

type VecTree b = FTree (Vec b)

Better yet, introduce an intermediate generalization, using the property that Vec b ≡ Trie (BNat b):

type TrieTree i = FTree (Trie i)

type VecTree b = TrieTree (BNat b)

With the exception of the most general form (FTree), these trees are also tries.

Generalizing and inverting our trees

The FTree type looks very like another data type that came up above, namely right-folded b-ary functor composition:

data (:^) ∷ (* → *) → * → (* → *) where
  ZeroC ∷             a  → (f :^ Z    ) a
  SuccC ∷ f ((f :^ n) a) → (f :^ (S n)) a

These two types are not just similar; they're identical (different only in naming, i.e., α-equivalent), so we can use f :^ n in place of FTree f n:

type TrieTree i = (:^) (Trie i)

Instead of right-folded functor composition, we could go with left-folded. What difference would it make to our notions of b-ary or binary trees?

First look at (right-folded) BinTree:

data BinTree ∷ * → * → * where
  Leaf   ∷                  a → BinTree Z     a
  Branch ∷ Pair (BinTree n) a → BinTree (S n) a

Equivalently,

data BinTree ∷ * → * → * where
  Leaf   ∷                         a → BinTree Z     a
  Branch ∷ (BNat TwoT ↛ BinTree n a) → BinTree (S n) a

With left-folding, the Branch constructors would be

  Branch ∷ BinTree n (Pair a) → BinTree (S n) a

or

  Branch ∷ BinTree n (BNat TwoT ↛ a) → BinTree (S n) a

Then (right-folded) VecTree:

data VecTree ∷ * → * → * → * where
  Leaf   ∷                        a → VecTree b Z     a
  Branch ∷ (BNat b ↛ VecTree b n a) → VecTree b (S n) a

Equivalently,

data VecTree ∷ * → * → * → * where
  Leaf   ∷                    a  → VecTree b Z     a
  Branch ∷ Vec b (VecTree b n a) → VecTree b (S n) a

With left-folding:

  Branch ∷ VecTree b n (BNat b ↛ a) → VecTree b (S n) a

or

  Branch ∷ VecTree b n (Vec b a) → VecTree b (S n) a

In shifting from right- to left-folding, our tree structuring becomes inverted. Now a "b-ary" tree really has only one subtree per branch node, not b subtrees.

For instance, right-folded a binary tree of depth two might look like

Branch (Branch (Leaf 0, Leaf 1), Branch (Leaf 2, Leaf 3))

For readability, I'm using normal pairs instead of 2-vectors or Pair pairs here. In contrast, the corresponding left-folded a binary tree would look like

Branch (Branch (Leaf ((0,1),(2,3))))

Note that the VecTree constructors are in a linear chain, forming an outer shell, and the number of such constructors is the one more than the depth, and hence logarithmic in the number of leaves. The right-folded form has VecTree constructors scattered throughout the tree, and the number of such constructors is exponential in the depth, and hence linear in the number of leaves. (As Sebastian Fischer pointed out, however, the number of pairing constructors is not reduced in the left-folded form.)

For more examples of this sort of inversion, see Chris Okasaki's gem of a paper From Fast Exponentiation to Square Matrices.

What sort of trees do we have?

I pulled a bit of a bait-and-switch above in reformulating trees. The initial infinite tree type had values and branching at every node:

data BinTree a = BinTree a (BinTree a) (BinTree a)

In contrast, the depth-typed trees (whether binary, b-ary, trie-ary, or functor-ary) all have strict separation of leaf nodes from branching nodes.

A conventional, finite binary tree data type might look like

data BinTree a = Leaf a | Branch (Pair (BinTree a))

Its inverted (left-folded) form:

data BinTree a = Leaf a | Branch (BinTree (Pair a))

When we had depth typing, the right- and left-folded forms were equally expressive. They both described "perfect" trees, with each depth consisting entirely of branching or (for the deepest level) entirely of values. (I'm speaking figuratively for the left-folded case, since literally there is no branching.)

Without depth typing, the expressiveness differs significantly. Right-folded trees can be ragged, with leaves occurring at various depths in the same tree. Left-folded binary trees of depth n can only be perfect, even though the depth is determined dynamically, not statically (i.e., not from type).

Dynamically-depthed binary trees generalize to b-ary, trie-ary, and functor-ary versions. In each case, the left-folded versions are much more statically constrained than their right-folded counterparts.

From here

This post is the last of a six-part series on tries and static size-typing in the context of numbers, vectors, and trees. Maybe you're curious where these ideas came from and where they might be going.

I got interested in these relationships while noodling over some imperative, data-parallel programs. I asked one one of my standard questions: What elegant beauty is hiding deep beneath these low-level implementation details. In this case, prominent details include array indices, bit fiddling, and power-of-two restrictions, which led me to play with binary numbers. Moreover, parallel algorithms often use a divide-and-conquer strategy. That strategy hints at balanced binary trees, which then can be indexed by binary numbers (bit sequences). Indexing brought memo tries to mind.

I expect to write soon about some ideas & techniques for deriving low-level, side-effecting, parallel algorithms from semantically simple and elegant specifications.

A trie for length-typed vectors

A vector is a trie over bounded numbers. What is a trie over vectors? As always, isomorphisms show us the way.

Vec n a → b ≅ (a × ⋯ × a) → b
             ≅ a → ⋯ → a → b
             ≅ a ↛ ⋯ ↛ a ↛ b
             ≡ Trie a (⋯ (Trie a b)⋯)
             ≅ (Trie a ∘ ⋯ ∘ Trie a) b

So the trie (functor) for Vec n a is the n-ary composition of tries for a:

type VTrie n a = Trie a :^ n 

where for any functor f and natural number type n,

f :^ n ≅ f ∘ ⋯ ∘ f  -- (n times)

N-ary functor composition

Since composition is associative, a recursive formulation might naturally fold from the left or from right. (Or perhaps in a balanced tree, to facilitate parallel execution.)

f :^ Z   ≅ Id
f :^ S n ≅ f ∘ (f :^ n)

data (:^) ∷ (* → *) → * → (* → *) where
  ZeroC ∷                        a  → (f :^ Z) a
  SuccC ∷ IsNat n ⇒ f ((f :^ n) a) → (f :^ (S n)) a

instance Functor f ⇒ Functor (f :^ n) where
  fmap h (ZeroC a)  = ZeroC (h a)
  fmap h (SuccC fs) = SuccC ((fmap∘fmap) h fs)

instance (IsNat n, Applicative f) ⇒ Applicative (f :^ n) where
  pure = pureN nat
  ZeroC f  ⊛ ZeroC x  = ZeroC (f x)
  SuccC fs ⊛ SuccC xs = SuccC (liftA2 (⊛) fs xs)

pureN ∷ Applicative f ⇒ Nat n → a → (f :^ n) a
pureN Zero     a = ZeroC a
pureN (Succ _) a = SuccC ((pure ∘ pure) a)

pureN (Succ n) a = SuccC ((pure ∘ pureN n) a)

  fmap = inZeroC  ($) ⊔ inSuccC  (fmap∘fmap)

  (⊛)  = inZeroC2 ($) ⊔ inSuccC2 (liftA2 (⊛))

inZeroC  h (ZeroC a ) = ZeroC (h a )

inSuccC  h (SuccC as) = SuccC (h as)

inZeroC2 h (ZeroC a ) (ZeroC b ) = ZeroC (h a  b )

inSuccC2 h (SuccC as) (SuccC bs) = SuccC (h as bs)

f :^ Z   ≅ Id
f :^ S n ≅ (f :^ n) ∘ f

data (:^) ∷ (* → *) → * → (* → *) where
  ZeroC ∷                        a  → (f :^ Z) a
  SuccC ∷ IsNat n ⇒ (f :^ n) (f a) → (f :^ (S n)) a

Vector tries (continued)

Using the analysis above, we can easily define tries over vectors as n-ary composition of tries over the vector element type. Again, there is a right-folded and a left-folded version.

instance (IsNat n, HasTrie a) ⇒ HasTrie (Vec n a) where
  type Trie (Vec n a) = Trie a :^ n

  ZeroC v `untrie` ZVec      = v
  SuccC t `untrie` (a :< as) = (t `untrie` a) `untrie` as

  trie = trieN nat

trieN ∷ HasTrie a ⇒ Nat n → (Vec n a → b) → (Trie a :^ n) b
trieN Zero     f = ZeroC (f ZVec)
trieN (Succ _) f = SuccC (trie (λ a → trie (f ∘ (a :<))))

instance (IsNat n, HasTrie a) ⇒ HasTrie (Vec n a) where
  type Trie (Vec n a) = Trie a :^ n

  ZeroC b `untrie` ZVec      = b
  SuccC t `untrie` (a :< as) = (t `untrie` as) `untrie` a
  
  trie = trieN nat

trieN ∷ HasTrie a ⇒ Nat n → (Vec n a → b) → (Trie a :^ n) b
trieN Zero     f = ZeroC (f ZVec)
trieN (Succ _) f = SuccC (trie (λ as → trie (f ∘ (:< as))))

Vec n a ≅ a × ⋯ × a
        ≅ (1 → a) × ⋯ × (1 → a)
        ≅ (1 + ⋯ + 1) → a

data BNat ∷ * → * where
  BZero ∷          BNat (S n)
  BSucc ∷ BNat n → BNat (S n)

data Vec ∷ * → * → * where
  ZVec ∷                Vec Z     a
  (:<) ∷ a → Vec n a → Vec (S n) a

data BNat ∷ * → * where
  BSucc ∷ BNat n → BNat (S n)
  BZero ∷          BNat (S n)

data Vec ∷ * → * → * where
  (:<) ∷ Vec n a → a → Vec (S n) a
  ZVec ∷                Vec Z     a

Deriving vectors

Recalling that Vec n a is an n-ary product of the type a, and forming the sort of derivation I used in Memoizing polymorphic functions via unmemoization,

Vec n a ≅ a × ⋯ × a
        ≅ (1 → a) × ⋯ × (1 → a)
        ≅ (1 + ⋯ + 1) → a

where the type 1 is what we call "unit" or "()" in Haskell, having exactly one (non-bottom) value. I used the isomorphism (a + b) → c ≅ (a → c) × (b → c), which corresponds to a familiar law of exponents: c^a + b = c^a × c^b.

So the sought domain type q is any type isomorphic to 1 + ⋯ + 1, which is to say a type consisting of exactly n choices.

We have already seen a candidate for the index type q, of which Vec n is the natural trie functor. The post Type-bounded numbers defines a type BNat n corresponding to natural numbers less than n, where n is a type-encoded natural number.

data BNat ∷ * → * where
  BZero ∷          BNat (S n)
  BSucc ∷ BNat n → BNat (S n)

These two constructors correspond to two axioms about inequality: 0 < n + 1 and m < n ⇒ m + 1 < n + 1. The type BNat n then corresponds to canonoical proofs that m < n for various values of m, where the proofs are built out of the two axioms and the law of modus ponens (which corresponds to function application).

Assuming a type n is built up solely from Z and S, a simple inductive argument shows that the number of fully-defined elements (not containing ⊥) of BNat n is the natural number corresponding to n (i.e., nat ∷ Nat n, where nat is as in the post Doing more with length-typed vectors).

Vectors as numbers

We've seen that Vec is a trie for bounded unary numbers, i.e., BNat n ↛ a ≡ Vec n a, using the notation from Elegant memoization with higher-order types. (Note that I've changed my pretty-printing from "k :→: v" to "k ↛ v".)

It's also the case that a vector of digits can be used to represent numbers:

type Digits n b = Vec n (BNat b)  -- n-digit number in base b

Or, more pleasing to my eye,

type Digits n b = BNat n ↛ BNat b

These representations can be given a little-endian or big-endian interpretation:

littleEndianToZ, bigEndianToZ ∷ ∀ n b. IsNat b ⇒ Digits n b → Integer

littleEndianToZ = foldr' (λ x s → fromBNat x + b * s) 0
 where b = natToZ (nat ∷ Nat b)

bigEndianToZ    = foldl' (λ s x → fromBNat x + b * s) 0
 where b = natToZ (nat ∷ Nat b)

The foldl' and foldr' are from Data.Foldable.

Give it a try:

*Vec> let ds = map toBNat [3,5,7] ∷ [BNat TenT]
*Vec> let v3 = fromList ds ∷ Vec ThreeT (BNat TenT)
*Vec> v3
fromList [3,5,7]
*Vec> littleEndianToZ v3
753
*Vec> bigEndianToZ v3
357

It's a shame here to map to the unconstrained Integer type, since (a) the result must be a natural number, and (b) the result is statically bounded by bⁿ.

An Applicative instance

As a review, here is our Functor instance:

instance Functor (Vec n) where
  fmap _ ZVec     = ZVec
  fmap f (a :< u) = f a :< fmap f u

And part of an Applicative instance:

instance Applicative (Vec n) where
  pure a = ??
  ZVec      ⊛ ZVec      = ZVec
  (f :< fs) ⊛ (x :< xs) = f x :< (fs ⊛ xs)

For pure, recall the troublesome goal signature:

  pure ∷ a → Vec n a

There's at least one very good reason this type is problematic. The type n is completely unrestricted. There is nothing to require n to be a natural number type, rather than Bool, String, String → Bool, etc.

In contrast to this difficulty with pure, consider what if n ≡ String in the type of fmap:

fmap ∷ (a → b) → Vec n a → Vec n b

The definition of Vec guarantees that that there are no values of type Vec String a. So it's vacuously easy to cover that case (with an empty function). Similarly for (⊛).

If we were to somehow define pure with the type given above, then pure () would have type Vec String () (among many other types). However, there are no values of that type. Hence, pure cannot be defined without restricting n.

Since the essential difficulty here is the unrestricted nature of n, let's look at restricting it. We'll want to include exactly the types that can arise in constructing Vec values, namely Z, S Z, S (S Z), S (S (S Z)), etc.

As a first try, define a class with two instances:

class IsNat n

instance IsNat Z
instance IsNat n ⇒ IsNat (S n)

Then change the Applicative instance to require IsNat n:

instance IsNat n ⇒ Applicative (Vec n) where
  ⋯

The definition of (⊛) given above still type-checks. Well, not quite. Really, the recursive call to (⊛) fails to type-check, because the IsNat constraint cannot be proved. One solution is to add that constraint to the vector type:

data Vec ∷ * → * → * where
  ZVec ∷ Vec Z a
  (:<) ∷ IsNat n ⇒ a → Vec n a → Vec (S n) a

Another is to break the definition (⊛) out into a separate recursion that omits the IsNat constraint:

instance IsNat n ⇒ Applicative (Vec n) where
  pure = ???
  (⊛)  = applyV

applyV ∷ Vec n (a → b) → Vec n a → Vec n b
ZVec      `applyV` ZVec      = ZVec
(f :< fs) `applyV` (x :< xs) = f x :< (fs `applyV` xs)

Now, how can we define pure? We still don't have enough structure. To get that structure, add a method to IsNat. That method could simply be the definition of pure that we need.

class IsNat n where pureN ∷ a → Vec n a

instance IsNat Z                where pureN a = ZVec
instance IsNat n ⇒ IsNat (S n) where pureN a = a :< pureN a

To get this second instance to type-check, we'll have to add the constraint IsNat n to the (:<) constructor in Vec. Then define pure = pureN for Vec.

I prefer a variation on this solution. Instead of pureN, use a method that can only make vectors of ():

class IsNat n where units ∷ Vec n ()

instance            IsNat Z     where units = ZVec
instance IsNat n ⇒ IsNat (S n) where units = () :< units

Then define

  pure a = fmap (const a) units

Neat trick, huh? I got it from Applicative Programming with Effects (section 7).

Value-typed natural numbers

There's still another way to define IsNat, and it's the one I actually use.

Define a type of natural number with matching value & type:

data Nat ∷ * → * where
  Zero ∷                    Nat Z
  Succ ∷ IsNat n ⇒ Nat n → Nat (S n)

Interpret a Nat as an Integer

natToZ ∷ Nat n → Integer
natToZ Zero     = 0
natToZ (Succ n) = (succ ∘ natToZ) n

I wrote the second clause strangely to emphasize the following lovely property, which corresponds to a simple commutative diagram:

natToZ ∘ Succ = succ ∘ natToZ

This natToZ function is handy for showing natural numbers:

instance Show (Nat n) where show = show ∘ natToZ

A fun & strange thing about Nat n is that it can have at most one inhabitant for any type n. We can synthesize that inhabitant via an alternative definition of the IsNat class defined (twice) above:

class IsNat n where nat ∷ Nat n

instance            IsNat Z     where nat = Zero
instance IsNat n ⇒ IsNat (S n) where nat = Succ nat

Using this latest version of IsNat, we can easily define units (and hence pure on Vec n for IsNat n):

units ∷ IsNat n ⇒ Vec n ()
units = unitsN nat

unitsN ∷ Nat n → Vec n ()
unitsN Zero     = ZVec
unitsN (Succ n) = () :< unitsN n

I prefer this latest IsNat definition over the previous two, because it relies only on Nat, which is simpler and more broadly useful than Vec. Examples abound, including improving an recent post, as we'll see now.

Revisiting type-bounded numbers

The post Type-bounded numbers defined a type BNat n of natural numbers less than n, which can be used, for instance, as numerical digits in base n.

data BNat ∷ * → * where
  BZero ∷          BNat (S n)
  BSucc ∷ BNat n → BNat (S n)

One useful operation is conversion from integer to BNat n. This operation had the awkward task of coming up with BNat structure. The solution given was to introduce a type class, with instances for Z and S:

class HasBNat n where toBNat ∷ Integer → Maybe (BNat n)

instance HasBNat Z where toBNat _ = Nothing

instance HasBNat n ⇒ HasBNat (S n) where
  toBNat m | m < 1     = Just BZero
           | otherwise = fmap BSucc (toBNat (pred m))

We can instead eliminate the HasBNat class and reuse the IsNat class, as in the last technique above for defining units or pure.

toBNat ∷ ∀ n. IsNat n ⇒ Integer → Maybe (BNat n)
toBNat = loop n where
  n = nat ∷ Nat n
  loop ∷ Nat n' → Integer → Maybe (BNat n')
  loop Zero      _ = Nothing
  loop (Succ _)  0 = Just BZero
  loop (Succ n') m = fmap BSucc (loop n' (pred m))

A Monad instance

First the easy parts: standard definitions in terms of pure and join:

instance IsNat n ⇒ Monad (Vec n) where
  return  = pure
  v >>= f = join (fmap f v)

The join function on Vec n is just like join for functions and for streams. (Rightly so, considering the principle of type class morphisms.) It uses diagonalization, and one way to think of vector join is that it extracts the diagonal of a square matrix.

join ∷ Vec n (Vec n a) → Vec n a
join ZVec      = ZVec
join (v :< vs) = headV v :< join (fmap tailV vs)

The headV and tailV functions are like head and tail but understand lengths:

headV ∷ Vec (S n) a → a
headV (a :< _) = a

tailV ∷ Vec (S n) a → Vec n a
tailV (_ :< as) = as

Unlike their list counterparts, headV and tailV are safe, in that the precondition of non-emptiness is verified statically.

Fixing lists

Is there a type of finite lists without choice points (sums)? Yes. There are lots of them. One for each length. Instead of having a single type of lists, have an infinite family of types of n-element lists, one type for each n.

In other words, to fix the problem with lists (trie-unfriendliness), split up the usual list type into subtypes (so to speak), each of which has a fixed length.

I realize I'm changing the question to a simpler one. I hope you'll forgive me and hang in to see where this ride goes.

As a first try, we might use tuples as our fixed-length lists:

type L0 a = ()
type L1 a = (a)
type L2 a = (a,a)
type L3 a = (a,a,a)
⋯

However, we can only write down finitely many such types, and I don't know how we could write any definitions that are polymorphic over length.

What can "polymorphic over length" mean in a setting like Haskell, where polymorphism is over types rather than values. Can we express numbers (for lengths, etc) as types? Yes, as in the previous post, Type-bounded numbers, using a common encoding:

data Z    -- zero
data S n  -- successor

Given these type-level numbers, we can define a data type Vec n a, containing only vectors (fixed lists) of length n and elements of type a. Such vectors can be built up as either the zero-length vector, or by adding an element to an vector of length n to get a vector of length n + 1. I don't know how to define this type as a regular algebraic data type, but it's easy as a generalized algebraic data type (GADT):

infixr 5 :<

data Vec ∷ * → * → * where
  ZVec ∷                Vec Z     a
  (:<) ∷ a → Vec n a → Vec (S n) a

For example,

*Vec> :ty 'z' :< 'o' :< 'm' :< 'g' :< ZVec
'z' :< 'o' :< 'm' :< 'g' :< ZVec ∷ Vec (S (S (S (S Z)))) Char

As desired, Vec is length-typed, covers all (finite) lengths, and allows definition of length-polymorphic functions. For instance, it's easy to map functions over vectors:

instance Functor (Vec n) where
  fmap _ ZVec     = ZVec
  fmap f (a :< u) = f a :< fmap f u

The type of fmap here is (a → b) → Vec n a → Vec n b.

Folding over vectors is also straightforward:

instance Foldable (Vec n) where
  foldr _ b ZVec      = b
  foldr h b (a :< as) = a `h` foldr h b as

Is Vec n an applicative functor as well?

instance Applicative (Vec n) where
  ⋯

We would need

pure ∷ a → Vec n a
(⊛)  ∷ Vec n (a → b) → Vec n a → Vec n b

The (⊛) method can be defined similarly to fmap:

  ZVec      ⊛ ZVec      = ZVec
  (f :< fs) ⊛ (x :< xs) = f x :< (fs ⊛ xs)

Unlike fmap and (⊛), pure doesn't have a vector structure to crawl over. It must create just the right structure anyway. You might enjoy thinking about how to solve this puzzle, which I'll tackle in my next post. (Warning: spoilers in the comments below.)