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