Abstract Nonsense: Rambling thoughts of a Category Theorist
Synopsis: Looking at things through the lens of category theory, where 'things' may be anything from writing a good (a really, awesomely good) piece of code to ... well, what else is there in this life?
Chapter 1: the List
We consider the list: to monad or not to monad.
We consider the monad: to monad or to comonad, and, if we consider the monad, shall we consider the monoidal implications that monad lends itself it to?
A monad is not intrinsically monoidal, but, then again, the monad and the comonad are not intrinsically functors, but thinking of monads and comonads and thinking of them not as functors is a blocker for me ... it gives me a bit of a headache, thinking of a monad (the triple (T, mu (or 'join'), eta (or 'unit')). I mean, it is simple to think of monads as monads only when considering the join function, but what is the point of eta if you are not thinking of the monad in terms of a functor?
So I do not consider the monad, or the comonad (W, epsilon (or extract), delta (or duplicate)) (definition from "Introduction to Higher-Order Categorical Logic), http://books.google.com/books?isbn=0521356539, as being independently or intrinsically defined from the functor, Fa, as, after all unit and extract are functorable.
Okay. So we consider lists. We can consider lists free of the monadic and comonadic implications, because, after all, a list is simply a structure, and can be viewed as tree-like structure, where we define
data list a = nil | (a, list a)
we see that, firstly list is monoidal on a where mzero = nil and mappend is easily defined as append or (++).
So, anywhere along the list, one can grab the pair, and the tree falls out of the structure:
(a, |->) -> (b, |->) -> nil
The pairwise operators, fst and snd, are head and tail on list a, and the fundamental constructor of the list is cons, where cons :: a -> list a -> list a
(which looks like a continuation, now that I look at it, OMG!)
(The continuation monad is the 'mother of all monads', and the continuation is the 'mother of all function calls,' perhaps?)
from cons, mappend is simply defined:
nil ++ b = b
a ++ b = cons (head a) (tail a ++ b)
Since list a is functor a (leaving aside nil) we have fmap for lists, too:
fmap f nil = nil
fmap f (head:tail) = cons (f head) (fmap f tail)
as you can see, list definitions lend themselves naturally to induction.
Okay. Lists qua lists (of course, as monoids and functors) are very easily defined in just a few lines of code in any programming language with any heft (I've demonstrated Haskell here, the definitions are similar in Java once monoid and functor are properly established as types. This requires that Arrows and functors be defined, but that is not part of the scope of this article ... it's hard, but doable).
Monadic Lists
Now let's consider the case of lists as monads.
First, monad:
class Monad m where
return :: a -> m a
join :: m (m a) -> m a
That definition is unusual in the programming community, but not to a categorist. Programmers are used to the more applicative definition of monad:
class MonadForProgrammersButNotForMeTheCategorist m where
return :: a -> m a
m >>= f :: m a -> (a -> m b) -> m b
The issue with defining monads in terms of bind (>>=) is that sometimes wrapping your head around what bind should be for a particular monad can be tricky (sometimes it isn't, but sometimes it is), but if one knows what join is for a monad, and, if that monad is a functor, then we have a very simple, and a very general, definition of bind:
bind m f = join . fmap f
proof
bind is defined as above
bind (m a) f = (join . fmap f) (m a) = m b (supposition)
= (join . fmap (a -> m b)) (m a)
= (join . (m a -> m (m b))) (m a)
= (join (m (m b)) = m b
Q.E.D.
So, given that we have join and fmap defined for a monad, bind falls out easily from their composition, and that's why I declare monads as per category theory, as being the triple of the monadic type, the unit function (in Haskell, it's called 'return') and the join function.
Now, the monadic aspect of list a is simply this:
instance Monad list where
return a = [a]
join [] = []
join (head:tail) = head ++ join tail (where head and tail are (monadic) lists)
... or join for list [a,b,c] is a ++ b ++ c.
And thus we have have monadic lists defined and may therefor use lists monadically, e.g.:
[1,2,3] >>= return . succ = [2,3,4]
and, even better:
[1,null, 3] >>= return . succ = [2,4]
It. Just. Works.
(side note: it really works in Haskell, as, after all, 'null' is not a number so the list [1,null, 3] does not exist in Haskell.
In Java, null very much exists, but if we make monadic list construction dependent on the monadicity of the units then the lifting function (which we will cover later) from a 'plain' list to the monadic list gets us into the a good position already:
return [1,null, 3] = [1,3] (monadic)
And if we don't do that, then the binding operation will use the Maybe type to guarantee the safety of the operation:
[1,null,3] >>= return . succ == succ (Just 1) : succ (Nothing) : succ (Just 3) = [2, 4]
end side note.)
Comonadic Lists
Now that we have monadic lists defined, let's define comonad lists.
Why? Because whereas with monads we have bind, which lends itself nicely to each element of lists, with comonads we have extend which also extends itself very nicely to operations on lists as a whole, iteratively reductively.
So, a comonad is
class Comonad w where
extract :: w a -> a
duplicate :: w a -> w (w a)
Again, instead of making extend intrinsic to the definition of comonads, I chose, instead, the mathematical definition, again, using duplicate.
Again, for gainful reasons, because extend can be defined in terms of duplicate:
extend :: w a -> (w a -> b) -> w b
Or:
extend f (w a) = (fmap f . duplicate) (w a) = w b (supposition)
proof:
extend f (w a) = (fmap f . duplicate) (w a)
= (fmap (w a -> b) . duplicate) (w a)
= ((w (w a) -> w b) . duplicate) (w a)
= ((w (w a) -> w b) (w (w a))
= w b
Q.E.D.
So for lists:
instance Comonad list where
extract [] = doesn't happen. Really
extract (head:_) = head
duplicate [] = []
duplicate list@(_:tail) = list : (duplicate tail)
... and we're done.
So, if we have the basic list type defined as (a, list a) or nil
Then we convert to mlist (monadic list) or wlist (comonadic list) by defining nil for each of the particular types and then just adding elements (with cons) to each of those container types:
asMonad [] = m[]
asMonad (h:t) = h m: asMonad t
asComonad [] = w[]
asComonad (h:t) = h w: asComonad t
and in the derived times
asMonad mlist = mlist
asComonad wlist = wlist
Piece of cake.
Or.
Is.
It?
Constructing Lists: Lists as Streams.
The 'problem' of these functional list types is that they look more like Stacks than Queue, so we can interact very easily with the most recent element and cdr down through the list in an orderly fashion, but if we have a preexisting list of one type and wish to view it from a different aspect, not only do we have to build it iteratively, but we have to make sure that iterative build is not penalized (linearly) for each insert at the end of the list (which turns out to be an exponential punishment).
How do we do this?
Lists are functions in a functional aspect.
So, the problem commonly faced by users of them in the functional domain is that when one has to construct a large one iteratively, one faces the problem of continuously appending the next element to the end of the list, and since naïve append is O(N) time (linear), then doing that, iteratively incurs a near O(N*N) time cost.
(side note: the cost is actually O(N*(N-1)/2) time)
What can we do about that?
Simple, actually, if you come from a Prolog programming background, just use difference lists.
A difference list is a list representation of a pair of lists, one list representing the whole and one representing a part of the this:
data dlist a = DL { realize :: list a -> list a }
In Prolog, logic variables are used to provide the (declarative) representation (and consequently, the implementation):
List = [1,2,3|L] - L
Since we have L and L is a part of the whole list, we have a reference into a latter part of the list that in standard list representations we do not. Further, as L can be anything, it can even be the 'end' of the list, and so 'prepending' onto L allows us, by consequence (actually: 'by accident') to 'postpend' onto the list we're working with.
We saw how to represent difference lists using unification and logic variables in Prolog. How do we represent difference lists functionally?
It comes down to the fundamental function of lists, cons:
cons :: a -> list a -> list a
that is, if we give cons an element and a list we get a cons'ed list in return.
What happens if we don't give cons the list to cons to, but instead, we defer it? We then get the partial or curried function:
(cons x) :: list a -> list a
Which is no different than before.
Or.
Is.
It?
Well, recall that a difference list is the difference of two lists. Look at the signature of (cons x) above and what do we have? We have a function that, when given a list, returns a list.
What is a difference list again? A think that, when given a list, gives the full list back.
(cons x), that is: the curried cons function, and the difference list type can be viewed as the same thing, and from that we have our difference list definition (of the realize function):
realize = cons x
So, given realize, we can define prepend and postpend operations:
prepend :: a -> dlist a -> dlist a
prepend x dl = DL { cons x . realize dl }
x |> dl = prepend x dl
postpend :: a -> dlist a -> dlist a
postpend x dl = DL { realize dl . cons x }
dl <| x = postpend x dl
So what? Well, for prepend, there's no big deal, the operation occurs in constant time, but so does cons for (regular) lists. But for postpend, the operation takes the same constant time, but for regular lists, if we were to define postpend in the regular fashion:
postpend :: a -> list a -> list a
postpend a list = list ++ [a]
we would be traversing to the tail of the list each time to append the new element, and that traversal incurs a linear-time cost. Upshot: postpend for regular lists has an O(n) cost, but for difference lists, it occurs in constant time.
And that's the payoff, if you are working with a large list from an external source and need to enlistify it in an order-preserving fashion, doing so with a regular list would incur an exponential cost (nearly O(N*N)) but using difference lists has a logarithmic flattening effect (O(2N)).
Using difference lists saved my bacon on a project where I did a scan-then-process operation on a framework that processes large documents.
Back to Java.
One way to convert from one representation of lists to another is to rebuild the list in the new type. Unfortunately, Java doesn't have the linear construct
mlist [] = m[]
mlist (h:t) = h m: mlist t
So what it does is iteratively build the new list with mappend (as lists are monoidal).
Well, using the O(N) mappend in an iterative fashion incurs an exponential-time cost for list-revisualization.
So, I've replaced my fromCollection() methods in Java from:
public static <L> L fromCollection(Collection coll, L basis) {
L ans = basis.mzero();
for(T elt : coll) {
ans = ans.mappend(basis.singleton(elt)); // exponential cost
}
return ans;
}
to be:
public static <L> L fromCollection(Collection coll, L basis) {
DifferenceList ans = DifferenceList.nil(basis);
for(T elt : coll) {
ans = ans.postpend(elt); // constant time cost
}
return ans.realizeFrom(basis);
}
so list construction that was at a cost of exponential time now become linear time, as it should be.
This way, I can work with a list either monadically or comonadically and pay only a linear cost when I change my (aspect) perspective on the list.
No comments:
Post a Comment