[Haskell-cafe] category design approach for inconvenient concepts

[Ertugrul Söylemez]

Christopher Howard <christopher.howard at frigidcode.com> wrote:

> Since I received the two responses to my question, I've been trying to
> think deeply about this subject, and go back and understand the core
> ideas. I think the problem is that I really don't have a clear
> understanding of the basics of category theory, and even less clear
> idea of the connection to Haskell programming. I have been reading
> every link I can find, but I'm still finding the ideas of "objects"
> and especially "morphisms" to be quite vague.

It's vague on purpose, or in better words it's abstract.  A category C
is a collection of objects called ob(C) and a collection of morphisms
hom(C) together with morphism composition that satisfies a few laws.
That's it.  It's up to you to interpret the objects and morphisms.
Different categories give rise to completely different interpretations.

What makes category theory interesting for programming is the set of
laws, because unlike the unspecified nature of objects and morphisms,
the laws are very specific.  They establish a rigorous notion of
soundness and locality.  Let's review these laws:

  * For all f : A -> B, g : B -> A:
        id A . g = g
        f . id A = f

This law is often understated.  It means that identity morphisms are
free of effects that could disturb composition.  It also means that the
composition does not change the nature of the component morphisms and is
free of effects that could disturb the neutrality of identity morphisms.

  * f . (g . h) = (f . g) . h

Not much to be said about this one, except that it makes composition
'lightweight' in a sense.  This basically means that you don't care how
compositions are grouped.

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.


> The original link I gave
> <http://www.haskellforall.com/2012_08_01_archive.html> purposely
> skipped over any discussion of objects, morphisms, domains, and
> codomains. The author stated, in his first example, that "Haskell
> functions" are a category, and proceeded to describe function
> composition. But here I am confused: If "functions" are a category,
> this would seem to imply (by the phrasing) that functions are the
> objects of the category. However, since we compose functions, and only
> morphisms are composed, it would follow that functions are actually
> morphisms. So, in the "function" category, are functions objects or
> morphisms? If they are morphisms, then what are the objects of the
> category?

You are absolutely right there.  The category is common called Hask, the
category of types and functions in Haskell.  It is strongly related to
the category of sets and functions, because Haskell types are actually
just sets, where every set has one additional member: bottom.  We say
that the set is 'lifted'.


Greets,
Ertugrul

-- 
Not to be or to be and (not to be or to be and (not to be or to be and
(not to be or to be and ... that is the list monad.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/haskell-cafe/attachments/20121219/7037ee36/attachment.pgp>