
Relation Between Type Theory, Category Theory and Logic - rndn
http://ncatlab.org/nlab/show/relation+between+type+theory+and+category+theory
======
Xcelerate
Can someone give me an absolute layman explanation to homotopy type theory
(and why it's so interesting)? I'm hearing about it everywhere, but most of
the introductions to the subject assume the reader is already familiar with
either type theory or category theory.

~~~
Kutta
Another addendum to the discussion, from an angle more relevant to computer
programmers: if we find a computational meaning for the univalence axiom, then
it'll be a crazy nuclear weapon of generic programming and code generation.

The univalence axiom says that two types are equal if we can convert their
values back and forth (without loss of information). For example, one Boolean
type may be defined as an enum containing True and False. But we could rename
the values to Foo and Bar and it would be still a fine implementation, because
it's easy to convert between the two representations. We can imagine more far-
fetched representations too, with more complicated conversion functions.

But in type theory, if two types are equal, then we can freely substitute one
for another in any context! For example, if we have a function "Bool -> Bool",
and we know that Bool is equal to Bool2, then we can coerce the function to
type "Bool2 -> Bool2".

Imagine a complex program that uses a complex piece of data type. If we can
provide a correct conversion function to another type (i. e. prove that the
type is equivalent to another one), then the univalence axiom can take the
conversion function and our program as input, and spits out a new program that
uses the new data type, and also preserves all properties of the program. By
our current standards of generic programming, this is just insane!

Now, the issue is that currently we don't actually have a computational
interpretation for the univalence axiom, so the above magic doesn't yet work.
But there is meaningful progress towards that, and there are already some
experimental implementations that can do some magic, for example this one:

[https://github.com/mortberg/cubicaltt](https://github.com/mortberg/cubicaltt)

~~~
rndn
Doesn't the halting problem pose an obstacle in deciding whether two types act
in an equivalent way (similar to how the equivalence between two programs is
undecidable)?

~~~
eli_gottlieb
No. Homotopy Type Theory is a total language, so even type-level programming
simply has to terminate, or the proof-checker won't accept it.

Proving that nontrivially recursive programs terminate can be a bugger.

------
AdieuToLogic
Something I looked for on this very intriguing site was a reconciliation in my
mind between dependent types and higher kinded types. This has been a nagging
question since the announcement of Scala moving to the DOT calculus[1].

While this page[2] helped a bit, doing more research unveiled an example put
out by Runar here[3].

Has anyone else considered a reasonable method for addressing what higher-
kinded types provide currently in a DOT calculus, especially as it pertains to
"matching" the type parameters in a higher-kinded type?

1 -
[http://lampwww.epfl.ch/~amin/dot/fool.pdf](http://lampwww.epfl.ch/~amin/dot/fool.pdf)

2 -
[http://ncatlab.org/nlab/show/dependent+type+theory](http://ncatlab.org/nlab/show/dependent+type+theory)

3 -
[https://gist.github.com/runarorama/33986541f0f1ddf4a3c7](https://gist.github.com/runarorama/33986541f0f1ddf4a3c7)

~~~
mafribe

       reconciliation in my mind between dependent types and higher kinded types. 
    

They are orthogonal concepts. This is made very clear in Barendregt's λ-cube
[1]. Orthogonal here means that a typing system might be higher-kinded without
allowing type-dependency, or it might allow type-dependency without having
higher-kinds. An example of the latter is LF, the Logical Framework of Harper
et al. Haskell, or at least some forms of Haskell are an example of the
former.

Higher-kinded types simply allow functions and function application _at the
type level_ which can take functions as arguments and can return functions.
For example (lambda x.x => bool) and (lambda xy. x => y) are functions at the
type level.

An example of a dependent type is List(2+4)[bool], of lists of length 6
carrying booleans. Here (2+4) is a program. This parameterisation happens
_without_ having type-functions.

[1]
[https://en.wikipedia.org/wiki/Lambda_cube](https://en.wikipedia.org/wiki/Lambda_cube)

------
noblethrasher
Also, see some of Robert Harper's lectures on the same subject:
[https://www.youtube.com/watch?v=9SnefrwBIDc&list=PLGCr8P_Ync...](https://www.youtube.com/watch?v=9SnefrwBIDc&list=PLGCr8P_YncjXRzdGq2SjKv5F2J8HUFeqN)

------
szany
See also Bob Harper's blog for a more leisurely exposition:

[https://existentialtype.wordpress.com/2011/03/27/the-holy-
tr...](https://existentialtype.wordpress.com/2011/03/27/the-holy-trinity/)

~~~
joe_the_user
"Imagine a world in which logic, programming, and mathematics are unified, in
which every proof corresponds to a program, every program to a mapping, every
mapping to a proof!"

The thing I never understood about statements of this sort is that in my
understanding of model theory, Godel's theorem and so-forth, a proof is a rare
thing. Most of the true statements in a given model don't have proofs. Any
consistent proof system admits an uncountable sets of independent theorems and
so-forth.

~~~
mafribe
While Goedel's first incompleteness theorem indeed shows that there will
always be true statements that don't follow from a given set of (computable)
axioms, this is almost never a problem in practise. It is hard to find natural
examples of such statements. Almost every mathematical statement (or its
negation) you or I can come up with is a consequence of the axioms of ZFC set
theory, or whatever other foundation you prefer.

~~~
joe_the_user
It doesn't follow in normal mathematical practice I think because
mathematicians want natural, sane axioms that lead to human understandable
models.

Computing already starts out much messier in its activities. Determining what
will happen when a large system gets input is tricky.

I'm not sure what could proved about the operations of a "deep neural net" for
example.

