Re: [Haskell-cafe] Category theory as a design tool

Hello Greg and Alexander, Thanks for your replies. Funnily, I happen to own the 3 books you mentionned :-) My interest in category theory is a long standing affair...
Note that owning a book, having read (most of) it and knowing a theory (or at least its principles and main concepts) is really quite a different
On 6/22/11 3:59 PM, Arnaud Bailly wrote: thing
from being able to apply it.
One of the big benefits I see to using category theory for dealing with programming languages comes from using CT as a generalized logic for equational reasoning. In particular, making use of the ideas of (co)limits and adjunctions in order to prove that something must behave in a particular way. This requires a bit of work to contort your thinking into the patterns of CT, but it means that once you can prove that something is a foo, then all the theorems about foos will apply. Just having a diagram and knowing it commutes doesn't tell you a whole lot, it just says that one particular equation holds. The real power comes from looking at diagrams that are parametric (since then proving it holds will mean it holds for all parameter valuations), or looking at diagrams where one of the arrows is (essentially) unique (since then you can show things that look like foos actually are foos). That is, the real power of diagrams comes from the quantifiers, which are explained in the text rather than shown in the diagram itself. As an example of this approach, see my comments in the thread about anonymous sum types. For something to be a product means that a particular diagram commutes: namely, a product is the limit of the two point category (and coproducts are the colimit). One of the many things this tells us is that if we posit that A*A ~ A in a category that "has products", we must infer that the category is a meet-(pre)semilattice[1]. [1] Or a really goofy structure where for every A and B there are at most two A->B, with a canonical way of distinguishing them. Of course, for this to be a category we need to define a composition operator, which will take the four compositions into the two possible arrows, which is where it gets strange. -- Live well, ~wren

On Wed, Jun 22, 2011 at 11:46 PM, wren ng thornton
One of the big benefits I see to using category theory for dealing with programming languages comes from using CT as a generalized logic for equational reasoning. In particular, making use of the ideas of (co)limits and adjunctions in order to prove that something must behave in a particular way. This requires a bit of work to contort your thinking into the patterns of CT, but it means that once you can prove that something is a foo, then all the theorems about foos will apply.
Yes, I can understand that and this is exactly what I am looking for. Except that I am looking for it not to deal with programming languages but with systems (and the way we design). Of course, we can always say that each system is a language of its own (rather than *has* a language...) which is what Eric Evans coined with its "Ubiquitous language" term. But I find it difficult to connect that particular dots.
As an example of this approach, see my comments in the thread about anonymous sum types. For something to be a product means that a particular diagram commutes: namely, a product is the limit of the two point category (and coproducts are the colimit). One of the many things this tells us is that if we posit that A*A ~ A in a category that "has products", we must infer that the category is a meet-(pre)semilattice[1].
I certainly won't argue with you on this given my limited knowledge of what a meet-(pre)semilattice could be :-) But then, if I happen to understand what it is, how could that help me design and code "better" systems? I have the intuition it could help me but again I do not (yet) see how. Thanks a lot for your answer Arnaud

Tjhis presentation has been very useful for me: Category Theory for software engineers,. http://www.cs.toronto.edu/~sme/presentations/cat101.pdf It is an excelent introduction using basic notations (graphs). It includes "Applying category theory to specifications" and "Tools based on category theory" An excerpt: "Reading maths books (especially category theory books!) is like reading a program without any of the supporting documentation. There’s lots of definitions, lemmas, proofs, and so on, but no indication of what it’s all for, or why it’s written the way it is. This also applies to many software engineering papers that explore formal foundations" Additionally I would say that reading category theory books is like readling a program with no monoonomorphic instances, no semantic structure, no imperative main function telling what is all the stuff for, and no purpose.
participants (3)
-
Alberto G. Corona
-
Arnaud Bailly
-
wren ng thornton