Recently I read this article I happened across, about the categorical design pattern: http://www.haskellforall.com/2012/08/the-category-design-pattern.html Barely understood it, of course, but it was a rather intriguing concept. So now I'm looking at all my programming problems trying to make types that can be composed and that seem to fit the idea of a "category". 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. To give a specific example (pseudo code like, without any idea here of implementation or proper syntax): 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). Presumably you would need a "Fail" constructor of some kind to represent the situation when there is not enough connectors. Say you had a C (coupler) with two connectors, a C (thing) with one connector, and a C (gadget) with one connector. So you could have... (coupler <.> thing) <.> gadget Because the coupler and the thing would combine to create a component with one spare connector. This would then combine with the gadget to make the final component. However, if you did... coupler <.> (thing <.> gadget) Then thing and gadget combine to make a component with no spare connectors. And so the new component and the coupler then fail to combine. Associativity law broken. So, can I adjust my idea to fit the "category" concept? Or is it just not applicable here? Or am I just misunderstanding the whole concept? -- frigidcode.com