# Difference between revisions of "User:Michiexile/MATH198/Lecture 5"

Michiexile (talk | contribs) |
Michiexile (talk | contribs) |
||

Line 44: | Line 44: | ||

which we can use as inspiration for an isomorphism <math>Hom(S,[T\to V]) = Hom(S\times T, V)</math> valid in Cartesian Closed Categories. |
which we can use as inspiration for an isomorphism <math>Hom(S,[T\to V]) = Hom(S\times T, V)</math> valid in Cartesian Closed Categories. |
||

+ | |||

+ | ---- |
||

+ | |||

+ | ====Typed lambda-calculus==== |
||

+ | |||

+ | The lambda-calculus, and later the ''typed'' lambda-calculus both act as foundational bases for computer science, and computer programming in particular. The idea in both is that everything is a function, and we can reduce the act of programming to function application; which in turn can be analyzed using expression rewriting rules that encapsulate the act of computation in a sequence of formal rewrites. |
||

+ | |||

+ | ''Definition'' A ''typed lambda-calculus'' is a formal theory with ''types'', ''terms'', ''variables'' and ''equations''. Each term <math>a</math> has a type <math>A</math> associated to it, and we write <math>a:A</math> or <math>a\in A</math>. The system is subject to a sequence of rules: |
||

+ | # There is a type <math>1</math>. ''Hence, the empty lambda calculus is excluded''. |
||

+ | # If <math>A, B</math> are types, then so are <math>A\times B</math> and <math>[A\to B]</math>. ''These are, initially, just additional symbols, not imbued with the associations we usually give the symbols used.'' |
||

+ | # There is a term <math>*:1</math>. ''Hence, the lambda calculus without any terms is excluded''. |
||

+ | # For each type <math>A</math>, there is an infinite (countable) supply of terms <math>x_A^i:A</math>. |
||

+ | # If <math>a:A, b:B</math> are terms, then there is a term <math>(a,b):A\times B</math>. |
||

+ | # If <math>c:A\times B</math> then there are terms <math>proj_1(c):A, proj_2(c):B</math>. |
||

+ | # If <math>a:A</math> And <math>f:[A\to B]</math>, then there is a term <math>f a:B</math>. |
||

+ | # If <math>x:A</math> is a variable and <math>\phi(x):B</math> is a term, then there is a <math>\lambda_{x\in A}\phi(x):[A\to B]</math>. ''Note that here, <math>\phi(x)</math> is a meta-expression, meaning we have SOME lambda-calculus expression that may include the variable <math>x</math>.'' |
||

+ | # There is a relation <math>a=_Xa'</math> for each set of variables <math>X</math> that occur freely in either <math>a</math> or <math>a'</math>. This relation is reflexive, symmetric and transitive. ''Recall that a variable is free in a term if it is not in the scope of a <math>\lambda</math>-expression naming that variable.'' |
||

+ | # If <math>a:1</math> then <math>a=_{\{\}}*</math>. ''In other words, up to lambda-calculus equality, there is only one value of type <math>*</math>.'' |
||

+ | # If <math>X\subseteq Y</math>, then <math>a=_Xa'</math> implies <math>a=_Ya'</math>. ''Binding more variables gives less freedom, not more, and thus cannot suddenly make equal expressions differ.'' |
||

+ | # <math>a=_Xa'</math> implies <math>f a=_Xf a'</math>. |
||

+ | # <math>f=_Xf'</math> implies <math>f a=_Xf' a</math>. ''So equality plays nice with function application.'' |
||

+ | # <math>\phi(x) =_{X\cup \{x\}} \phi'(x)</math> implies <math>\lambda_x \phi(x) =_X \lambda_x \phi'(x)</math>. ''Equality behaves well with respect to binding variables.'' |
||

+ | # <math>proj_1(a,b) =_X a</math>, <math>proj_2(a,b) =_Xb</math>, <math>c=_X(proj_1(c),proj_2(c))</math> for all <math>a,b,c,X</math>. |
||

+ | # <math>\lambda_x\phi(x) a =_X \phi(a)</math> if <math>a</math> is substitutable for <math>x</math> in <math>\phi(x)</math> and <math>\phi(a)</math> is what we get by substituting each occurrence of <math>x</math> by<math>a</math> in <math>\phi(x)</math>. ''A term is '''substitutable''' for another if by performing the substitution, no occurrence of any variable in the term becomes bound,'' |
||

+ | # <math>\lambda_{x\in A}f x =_X f, provided <math>x\not\in X</math>. |
||

+ | # <math>\lambda_{x\in A}\phi(x) =_X \lambda_{x'\in A}\phi(x')</math> if <math>x'</math> is substitutable for <math>x</math> in <math>\phi(x)</math> and each variable is not free in the other expression. |
||

+ | |||

+ | Note that <math>=_X</math> is ''just a symbol''. The axioms above give it properties that work a lot like equality, but two lambda calculus-equal terms are not equal unless they are identical. However, <math>a=_Xb</math> tells us that in any ''model'' of this lambda calculus - where terms, types, et.c. are replaced with actual things (mathematical objects, say, or a programming language semantics embedding typed lambda calculus) - ''then'' the things given by translating <math>a</math> and <math>b</math> into the model should end up being equal. |
||

+ | |||

+ | Any actual realization of typed lambda calculus is bound to have more rules and equalities than the ones listed here. |
||

+ | |||

+ | With these axioms in front of us, however, we can see how lambda calculus and Cartesian Closed Categories fit together: We can go back and forth between the wo concepts in a natural manner: |
||

+ | |||

+ | =====CCC to Lambda===== |
||

+ | |||

+ | Given a typed lambda calculus <math>L</math>, we can define a CCC <math>C(L)</math>. Its objects are the types of <math>L</math>. An arrow from <math>A</math> to <math>B</math> is an equivalence class (under <math>=_{\{x\}}</math>) of terms of type <math>B</math>, free in a single variable <math>x:A</math>. |
||

+ | |||

+ | We need the equivalence classes because for any variable <math>x:A</math>, we want <math>\lambda_xx: 1\to [A\to A]</math> to be the global element of <math>[A\to A]</math> corresponding to the identity arrow. Hence, that variable must itself correspond to an identity arrow. |
||

+ | |||

+ | And then the rules for the various constructions enumerated in the axioms correspond closely to what we need to prove the resulting category to be cartesian closed. |
||

+ | |||

+ | =====Lambda to CCC===== |
||

+ | |||

+ | ---- |
||

+ | More on this subject can be found in: |
||

+ | * Lambek & Scott: ''Aspects of higher order categorical logic'' and ''Introduction to higher order categorical logic'' |
||

---- |
---- |
||

Line 51: | Line 97: | ||

More importantly, by stating <math>\lambda</math>-calculus in terms of a CCC instead of in terms of ''terms'' and ''rewriting rules'' is that you can escape worrying about variable clashes, alpha reductions and composability - the categorical translation ignores, at least superficially, the variables, reduces terms with morphisms that have equality built in, and provides associative composition ''for free''. |
More importantly, by stating <math>\lambda</math>-calculus in terms of a CCC instead of in terms of ''terms'' and ''rewriting rules'' is that you can escape worrying about variable clashes, alpha reductions and composability - the categorical translation ignores, at least superficially, the variables, reduces terms with morphisms that have equality built in, and provides associative composition ''for free''. |
||

− | At this point, I'd |
+ | At this point, I'd recommend reading more on Wikipedia [http://en.wikipedia.org/wiki/Lambda_calculus] and [http://en.wikipedia.org/wiki/Cartesian_closed_category], as well as in Lambek & Scott: Introduction to Higher Order Categorical Logic. The book by Lambek & Scott goes into great depth on these issues, but may be less than friendly to a novice. |

Line 78: | Line 124: | ||

===Homework=== |
===Homework=== |
||

# Prove that currying/uncurrying are isomorphisms in a CCC. Hint: the map <math>f\mapsto\lambda f</math> is a map <math>Hom(C\times A, B)\to Hom(C,[A\to B])</math>. |
# Prove that currying/uncurrying are isomorphisms in a CCC. Hint: the map <math>f\mapsto\lambda f</math> is a map <math>Hom(C\times A, B)\to Hom(C,[A\to B])</math>. |
||

+ | # Prove that in a CCC, the composition <math>\lambda \circ ev</math> is <math>\lambda\circ ev = 1_{[A\to B]}: [A\to B] \to [A\to B]</math>. |
||

+ | # * Implement a typed lambda calculus as an EDSL in Haskell. |

## Revision as of 18:30, 19 October 2009

IMPORTANT NOTE: THESE NOTES ARE STILL UNDER DEVELOPMENT. PLEASE WAIT UNTIL AFTER THE LECTURE WITH HANDING ANYTHING IN, OR TREATING THE NOTES AS READY TO READ.

## Contents

### Cartesian Closed Categories and typed lambda-calculus

A category is said to *have pairwise products* if for any objects , there is a product object .

A category is said to *have pairwise coproducts* if for any objects , there is a coproduct object .

Recall when we talked about internal homs in Lecture 2. We can now define what we mean, formally, by the concept:

*Definition* An object in a category is an *internal hom object* or an *exponential object* or if it comes equipped with an arrow , called the *evaluation arrow*, such that for any other arrow , there is a unique arrow such that the composite

is .

The idea here is that with something in an exponential object, and something in the source of the arrows we imagine live inside the exponential, we can produce the evaluation of the arrow at the source to produce something in the target. Using global elements, this reasoning comes through in a more natural manner: given and we can produce the global element . Furthermore, we can always produce something in the exponential whenever we have something that looks as if it should be there.

And with this we can define

**Definition** A category is a *Cartesian Closed Category* or a CCC if:

- has a terminal object
- Each pair of objects has a product and projections , .
- For every pair of objects, there is an exponential object with an evaluation map .

#### Currying

Note that the exponential as described here is exactly what we need in order to discuss the Haskell concept of multi-parameter functions. If we consider the type of a binary function in Haskell:

```
binFunction :: a -> a -> a
```

This function really lives in the Haskell type `a -> (a -> a)`

, and thus is an element in the repeated exponential object . Evaluating once gives us a single-parameter function, the first parameter consumed by the first evaluation, and we can evaluate a second time, feeding in the second parameter to get an end result from the function.

On the other hand, we can feed in both values at once, and get

```
binFunction' :: (a,a) -> a
```

which lives in the exponential object .

These are genuinely different objects, but they seem to do the same thing: consume two distinct values to produce a third value. The resolution of the difference lies, again, in a recognition from Set theory: there is an isomorphism

which we can use as inspiration for an isomorphism valid in Cartesian Closed Categories.

#### Typed lambda-calculus

The lambda-calculus, and later the *typed* lambda-calculus both act as foundational bases for computer science, and computer programming in particular. The idea in both is that everything is a function, and we can reduce the act of programming to function application; which in turn can be analyzed using expression rewriting rules that encapsulate the act of computation in a sequence of formal rewrites.

*Definition* A *typed lambda-calculus* is a formal theory with *types*, *terms*, *variables* and *equations*. Each term has a type associated to it, and we write or . The system is subject to a sequence of rules:

- There is a type .
*Hence, the empty lambda calculus is excluded*. - If are types, then so are and .
*These are, initially, just additional symbols, not imbued with the associations we usually give the symbols used.* - There is a term .
*Hence, the lambda calculus without any terms is excluded*. - For each type , there is an infinite (countable) supply of terms .
- If are terms, then there is a term .
- If then there are terms .
- If And , then there is a term .
- If is a variable and is a term, then there is a .
*Note that here, is a meta-expression, meaning we have SOME lambda-calculus expression that may include the variable .* - There is a relation for each set of variables that occur freely in either or . This relation is reflexive, symmetric and transitive.
*Recall that a variable is free in a term if it is not in the scope of a -expression naming that variable.* - If then .
*In other words, up to lambda-calculus equality, there is only one value of type .* - If , then implies .
*Binding more variables gives less freedom, not more, and thus cannot suddenly make equal expressions differ.* - implies .
- implies .
*So equality plays nice with function application.* - implies .
*Equality behaves well with respect to binding variables.* - , , for all .
- if is substitutable for in and is what we get by substituting each occurrence of by in .
*A term is***substitutable**for another if by performing the substitution, no occurrence of any variable in the term becomes bound, - .
- if is substitutable for in and each variable is not free in the other expression.

Note that is *just a symbol*. The axioms above give it properties that work a lot like equality, but two lambda calculus-equal terms are not equal unless they are identical. However, tells us that in any *model* of this lambda calculus - where terms, types, et.c. are replaced with actual things (mathematical objects, say, or a programming language semantics embedding typed lambda calculus) - *then* the things given by translating and into the model should end up being equal.

Any actual realization of typed lambda calculus is bound to have more rules and equalities than the ones listed here.

With these axioms in front of us, however, we can see how lambda calculus and Cartesian Closed Categories fit together: We can go back and forth between the wo concepts in a natural manner:

##### CCC to Lambda

Given a typed lambda calculus , we can define a CCC . Its objects are the types of . An arrow from to is an equivalence class (under ) of terms of type , free in a single variable .

We need the equivalence classes because for any variable , we want to be the global element of corresponding to the identity arrow. Hence, that variable must itself correspond to an identity arrow.

And then the rules for the various constructions enumerated in the axioms correspond closely to what we need to prove the resulting category to be cartesian closed.

##### Lambda to CCC

More on this subject can be found in:

- Lambek & Scott:
*Aspects of higher order categorical logic*and*Introduction to higher order categorical logic*

As it turns out, this is exactly what we need for -calculus. Any typed -calculus gives rise to a CCC in a natural manner, and any CCC has an *internal language* which satisfies, by the axioms for the CCC, all requirements to be a typed -calculus.

More importantly, by stating -calculus in terms of a CCC instead of in terms of *terms* and *rewriting rules* is that you can escape worrying about variable clashes, alpha reductions and composability - the categorical translation ignores, at least superficially, the variables, reduces terms with morphisms that have equality built in, and provides associative composition *for free*.

At this point, I'd recommend reading more on Wikipedia [1] and [2], as well as in Lambek & Scott: Introduction to Higher Order Categorical Logic. The book by Lambek & Scott goes into great depth on these issues, but may be less than friendly to a novice.

### Limits and colimits

- Generalizing these constructions
- Diagram and universal object mapping to (from) the diagram
- Express product/coproduct as limit/colimit
- Issues with Haskell
- No dependent types
- No compiler-enforced equational conditions
- Can be
*simulated*but not enforced, e.g. using QuickCheck.

#### Useful limits and colimits

##### Equalizer, coequalizer

- Kernels, cokernels, images, coimages
- connect to linear algebra: null spaces et.c.

##### Pushout and pullback squares

- Computer science applications

### Homework

- Prove that currying/uncurrying are isomorphisms in a CCC. Hint: the map is a map .
- Prove that in a CCC, the composition is .
- * Implement a typed lambda calculus as an EDSL in Haskell.