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. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe