[Haskell-cafe] category design approach for inconvenient concepts

[Christopher Howard]

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 553 bytes
Desc: OpenPGP digital signature
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121218/4ae866ea/attachment.pgp>