On 12/18/2012 08:02 PM, Gershom Bazerman wrote:
On 12/17/12 9:45 PM, Christopher Howard wrote:
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 think the example I gave was pretty messed up anyway, because I was trying to compose objects rather than morphisms. But that directional aspect you mentioned does seem significant... so I guess my main question is how that things that are more complex (like a multi-directional system built from pluggable components) could be represented in the Categorical manner. I'm looking for the Grand Unifying Theory to follow, if you will; I really like the idea that all parts of my program could be cleanly and systematically composed from smaller pieces, in some beautiful design patter. Many of the problems in my practical programming, however, are not like the examples I have seen (nice pipes or unidirectional calculations) but rather complex fitting together of components. E.g., space ships are made up of guns + engines + shields + ammo. Different kinds of space ships may use the same kind of guns (reusable components) but some wont. Some will have many guns, some will have none. And such like issues. Soylemez seems to have answered this issue directly in his reply. Unfortunately, I didn't understand most of what he wrote. :|
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?
The example I gave was hastily put together and not well thought out. I was Just trying to come up with something that would convey the general idea. But perhaps each component would have a list of connectors, and the first ones in the list would be used first. When a new component was created from other components, the new list would be taken from the leftover connectors (if any). In real world use I would probably have multiple types of connectors, but I haven't thought that far ahead.
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
Sounds good. Of course, I still haven't figured out what design pattern to fit said types into. :( -- frigidcode.com