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.