Comments on: Doing more with length-typed vectors

By: conal

conal — Mon, 07 Feb 2011 04:40:08 +0000

Thanks, Eyal. I had forgotten about (<$).

By: Eyal Lotem

Eyal Lotem — Sun, 06 Feb 2011 21:15:45 +0000

Everyone might already know this, but (<$) = fmap . const, so the above:

pure a = fmap (const a) units

Can be written:

pure a = a <$ units

or:

pure = (<$ units)

By: Conal Elliott » Blog Archive » A trie for length-typed vectors

Conal Elliott » Blog Archive » A trie for length-typed vectors — Tue, 01 Feb 2011 06:27:04 +0000

[...] Doing more with length-typed vectors [...]

By: Bas van Dijk

Bas van Dijk — Mon, 31 Jan 2011 19:41:31 +0000

Nice post Conal!

We should realy invent a name for this pattern where we have a “type level datatype” (like Z and S n), an isomorphic value level GADT (like Nat) and a class that provides an overloaded constructor for this GADT (like IsNat).

I used this same pattern in 3 places already:

I’m even thinking about using some CPP hackery to abstract the pattern.

By: Conal Elliott » Blog Archive » Reverse-engineering length-typed vectors

Mon, 31 Jan 2011 17:53:17 +0000

[...] About « Doing more with length-typed vectors [...]

By: Darius Jahandarie

Darius Jahandarie — Mon, 31 Jan 2011 17:35:00 +0000

Or, whenever this gets finished…

data Nat = Z | S Nat -- automatically lifted to the type/kind level!

data Vec :: Nat -> * -> * where
  ZVec :: Vec Z a
  (:<) :: a -> Vec n a -> Vec (S n) a

class Pure n where pureN :: a -> Vec n a

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

instance Applicative (Vec n) where
  pure a = pureN a
  ZVec <*> ZVec = ZVec
  (f :< fs) <*> (x :< xs) = f x :< (fs <*> xs)

Or something like that

By: Mikael Bung

Mikael Bung — Mon, 31 Jan 2011 13:16:47 +0000

Some time ago I tried to find a solution that didn’t require an extra restriction on the context. As far as I can tell the IsNat solution is the best (in the sense that you only need to carry around one context) you can do currently but Maximes solution together with http://hackage.haskell.org/trac/ghc/wiki/KindSystem looks like it would allow the compiler to convince itself that the Applicative instance exists for all possible Vec n.

By: conal

conal — Mon, 31 Jan 2011 01:25:06 +0000

Maxime Henrion suggested an alternative to my Applicative instance above:

instance Applicative (Vec Z) where
  pure _ = ZVec
  ZVec ⊛ ZVec = ZVec

instance Applicative (Vec n) ⇒ Applicative (Vec (S n)) where
  pure a = a :< pure a
  (f :< fs) ⊛ (a :< as) = f a :< (fs ⊛ as)

I hadn’t considered splitting the one instance into two. I like the simplicity of this solution, though I suspect the constraint Applicative (Vec n) would be cumbersome in practice. A small drawback of this version is that it requires the GHC language extensions FlexibleInstances and FlexibleContexts.

Continuing on to Monad:

instance Monad (Vec Z) where
  return  = pure
  v >>= f = joinZ (fmap f v)

instance Monad (Vec n) ⇒ Monad (Vec (S n)) where
  return  = pure
  v >>= f = joinS (fmap f v)

joinZ ∷ Vec Z (Vec Z a) → Vec Z a
joinZ ZVec = ZVec

joinS ∷ Monad (Vec n) ⇒ Vec (S n) (Vec (S n) a) → Vec (S n) a
joinS (v :< vs) = headV v :< join (fmap tailV vs)

In this case, I'm using the general join function on monads. The Monad instances would be more elegant and perhaps more efficient if join were a method on Monad as has been proposed.