I didn't get the + operation on types until he compared it to C's union. I don't know why he didn't appeal to the logical operations "and" and "or" for * and +, because that's what finally made them click and be consistent for me. For example, you can read int * int as "A type with an int and an int," and you can read int + int as "A type with an int on the left or an int on the right."
There's a parallelism all the way through (Tuple, Either), (*, +), (and, or), and (intersect, union) depending on the language you want to use and the underlying objects they're operating on.
Each is a (blurry) picture of algebraic ring structure.
It's important to remember that + is a little different from a C union in that it's automatically tagged, which C unions are not. If you have int+int in a functional language, you always know which arm was chosen. If you have a union of two ints in C you have to add a third boolean field yourself to keep track of which one is active.
Right, it's a tagged union. I mean conceptually. You still end up with the same domain of objects as a union. The tag just tells you which domain you're object is in. (Or which side rather, since the domains can intersect.)
This is a great explanation of algebraic datatypes!
The notion of one-hole context, its connection to differentiation, and its application to zippers is really interesting stuff. Another (much more detailed) discussion of it can be found here: http://en.wikibooks.org/wiki/Haskell/Zippers
Agreed, the "if this looks like a derivative it's because it is" punchline made my jaw drop. I <i>never</i> expected to see calculus show up when discussing ADT's and mutation.
The notion is so contrary to the way I'm used to thinking about programming and yet so appropriate given that mutation is change and a derivative describes the rate of change.
The links to the papers by Conor McBride are broken, but you can find them here: http://strictlypositive.org/publications.html