On Tue, Dec 18, 2012 at 4:49 PM, Ertugrul Söylemez
These laws make morphisms isolated and composition lightweight as well as undisturbing. Now try to transfer these notions to a concrete category, for example the category of web servers: The objects are sets and a morphism f : A -> B is a function from A × Request to B.
Expanding on this point, we can "refactor" how we "present" this category, using laws from basic category theory, so that f :: (A, Request) -> B f :: A -> Request -> B f :: A -> (Request -> B) f :: (A -> Request) -> B (this one isn't very useful to a programmer) f :: a -> Request B (by lifting a concrete Request object into a functor of the form (Request a)) etc, are all "equivalent", insofar as they merely present different interfaces to the same data. Note that these are distinct as "presentations", but equivalent as categories ("isomorphic", up to decidability -- the one I said wasn't useful really isn't, because "as a matter of fact", we can't decidably analyze/deconstruct a function (g :: A -> Request) to produce a B). This should make architectural decisions easy (or hard) -- once you have decided to use a category at all, you merely have to choose the presentation for the category that satisfies other requirements.