[Haskell-cafe] category design approach for inconvenient concepts

[Richard O'Keefe]

On 18/12/2012, at 3:45 PM, Christopher Howard wrote:
> Recently I read this article I happened across, about the categorical
> design pattern:
> 
> http://www.haskellforall.com/2012/08/the-category-design-pattern.html

It's basically the very old idea that an Abstract Data Type
should be a nice algebra: things that look as though they
ought to fit together should just work, and rearrangements
of things ought not to change the semantics in surprising
ways (i.e., Don't Be SQL).

> However, what I'm wondering about is ideas that can be "composed" but
> that don't seem to fit the idea of "category", because they don't obey
> the associativity law.

> Say you created a type called "Component" (C for short), the idea being
> to compose Components out of other Components. Every C has zero or more
> connectors on it. Two Cs can be connected to form a new C using some
> kind of composition operator (say, <.>), provided there are enough
> connectors (one on each).

Categories contain two things:
    "objects"
and "arrows" that connect objects.  Some important things about arrows:
 - for any object x there must be an identity id<x> : x -> x
 - any two compatible arrows must compose in one and only one way:
   f : x -> y & g : y -> z  =>  g . f : x -> z
 - composition must be associative (f . g) . h = f . (g . h)
   when the arrows fit together.

Of course for any category there is a dual category,
so what I'm about to say doesn't really make sense,
but there's sense in it somewhere:  the things you are
trying to hook together with your <.> operator seem to me more
like objects than arrows, and it does not seem as if
they hook together in one and only one way, so it's not so
much _associativity_ being broken, as the idea of <.> being
a composition in the first place.