[Haskell-cafe] category design approach for inconvenient concepts

[Gershom Bazerman]

On 12/17/12 9:45 PM, Christopher Howard wrote:
> 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?

I don't think you're describing a "Category" in the sense of the Haskell 
Category typeclass. But that's ok! Just because some things are 
categories and are nice doesn't mean that we can't have other nice 
things that aren't necessarily categories. My first thought was 
something with multiple inputs and one output is often an Operad 
(http://en.wikipedia.org/wiki/Operad_theory) but associativity is still 
an issue. Also bear in mind that operads and categories are both 
*directional* whereas your notion of coupling doesn't seem to be (which 
has something to do with associativity failing, I'd imagine).

I also don't understand, e.g., what happens if I couple a thing with two 
connectors and one connector -- which connector from the first gets 
used, or are they interchangeable?

Going back even further, you've suggested a "Fail" to represent when the 
connectors don't match. Why not start with encoding connectors in types 
to begin with, so that it is a type error to not have matching 
connectors? Follow the logic of your idea, shape your types to match 
your representable states, and then see what algebraic structures 
naturally emerge.

Cheers,
Gershom

P.S. I think you're right to be confused by that article. It's 
confusingly written, and I think is a poor entry point into either 
category theory as such or even the proper use of the Category typeclass 
in Haskell.