Re: My current readings in Category Theory

[Tim May]

On Wednesday, April 3, 2002, at 06:54  AM, Julian Assange wrote:
> Category theory is nice, but would be nicer if could draw in
> information theoretic and cognitive metaphors. Maths is a programming
> language selected over time for execution on (perhaps slightly
> modified) human brains. The failure to recognize this deeply held
> anthropomorphism is excusable in other areas of mathematics, but
> not in foundational studies.  Human beings look at the world through
> their own mental "axioms" which have evolved to understand the
> physical world and each other.  These axioms must be chased down
> and stated instead of allowing them to subtly invade the mathematical
> process.  For category theory, this failing likely evolved from
> its birth as a theory of mathematical classification as opposed to
> a theory of _origin_, although to be fair no foundational theory
> seems to be free of it.

Many thanks for your comments, Julian! I have already downloaded the Mac 
OS X version of O'Caml 3.04, though installation has hit a snag, which 
I'll have to investigate later.

About using more human-centric methods, maybe there's hope. Though CT is 
usually seen as notoriously abstract, the fact that it uses diagrams to 
understand functors and commuting maps, and so on, is nice. The Lawvere 
book is filled with diagrams and maps...and I mean a _lot_ of them, not 
just the canonical diagrams Mac Lane, for example, uses. (I'm not 
knocking Mac Lane...it isn't meant as a teaching intro.)
>

> About 15 years ago category theory leaked into programming language
> design. See http://www.haskell.org/ and http://www.ocaml.org/ (yes,
> thats me) for the two major real-world-useful category theory
> inspired languages.

I had followed ML a little bit, back when I was attending some of the 
Functional Programming conferences in the mid-80s. I must've paid no 
attention to the CT stuff (understanding denotational semantics was 
struggle enough, a struggle I gave up on when I moved on to other 
things).
>
> OO programming is classification from above. Classification
> comes first and is then acts as (an often inconsistent and poorly
> realized) behavioral constraint. For category theory inspired
> languages, classification (types) are inferred from _behavior_. For
> these languages, behavioral inconsistency is discovered by the
> inability to come to consistent classification which describes it.

This is a powerful insight. To pick an example from Smalltalk, with 
which I'm more familiar, an object is more defined by the methods 
(functions) it understands than anything else. To pick a list-related 
example: A banker is one who understand (sends, receives, processes) 
messages about deposits and withdrawals, more so than what he is called.

("You take in deposits and you hold money and you give out money in 
withdrawals, so I don't care _what_ you call yourself: you're a bank.")

This does not mean using class-derived objects is not useful: if the 
work has been done to define a "banker factory" class, with all of the 
functions/methods already worked out, then it makes sense to instantiate 
new banks from this factory class.

As I understand it, category theory actually treats the categories 
(objects) themselves as secondary, almost superfluous, with the 
interesting parts being the mappings or functions and then the 
transformations (functors) of these mappings being where things get more 
interesting.

(And if a compiler is a function or mapping from one category (source 
code) into another category (compiled, or executable code), then talking 
about compilers and the connections between them is an obvious area 
where functors, adjoints, and so on would come in. Hence the close 
connection of CT to computability theory, the lambda calculus, and so 
on.)

Another interesting area seems to be using CT for linguistics. Image 
English nouns as a category, French nouns as a category, and then the 
mappings (isomorphisms being the "exact" translations) between them. 
E.g., dog ---> chien.

(So far, high school simple functions.)

But there are other morphisms, such as the function or process of 
"forming plurals" or "possessives." These are maps as well.

Then one might look at the transformations (rules) between these maps, 
and between other languages. And connections to machine languages and 
grammars.

Using theorems about functors, adjoints, etc., one might make better 
sense of natural languages than by using conventional methods. (And the 
links with the above example are suggestive as well.)

Or consider a very difficult problem, one explained in great detail by 
Douglas Hofstadter in "Godel, Escher, Bach" (or possibly "Metamagical 
Themas"...I'd have to check). Namely, the many forms of the letter "A" 
and how humans can recognize them all as examples of "A" because of 
their "A"-ness (no jokes, please), but how computer programs have 
generally failed, even with all the buzzword-compliant tricks like 
neural nets and expert systems.

(Hofstadter shows a picture of many (at least 64) different "A," from 
script As, to slanted As, to highly abstract As, to stylized As, to As 
in Gothic script and other languages, and so on. Essentially all of them 
are recognizable by human readers with a modicum of intelligence as 
exemplars of the abstract category "A.")

Inasmuch as some of these are recognizable by counting holes (but not 
all As have holes), and some involve affine transformations (tilts, 
stretches), and so on, one might think that a mixture of methods from 
geometry and topology would be useful...methods humans understand at a 
very early age without any formal training. (Which goes to Julian's 
point about human methods....)

Perhaps CT could be helpful in understanding how we recognize "A"-ness 
(or many other things) even when multiple transformations have 
occurred...and for abstracting out the learning by looking at the 
transformations between the transformations.

This is not a Cypherpunks project, obviously, but shows why these kinds 
of methods might be useful (emphasis on "might") be useful for problems 
which have been hard to attack with straightforward ways (e.g. the 
"ordinary sets and simple functions" methods that Sempo S. mentioned).

As for ML and O'Caml, I plan to spend more time looking at this. Thanks, 
Julian, for the references. I have heard essentially nothing about Caml 
or O'Caml here in the U.S., but the Web site you referenced, and the 
O'Reilly book available in HTML, suggests there's a more active 
community than I would have thought.



--Tim May
"As my father told me long ago, the objective is not to convince someone
  with your arguments but to provide the arguments with which he later
  convinces himself." -- David Friedman