I think Bob is drawing an informal distinction between types which can be regarded meaningfully as theorems in a logic, and types which only express constructions (whatever that means). When people first learn about props-as-types, they are told that every program proves a theorem; they often respond with a question like, “What theorem does fib :: Int -> Int prove?” The answer is of course that it’s a useless theorem (\x. 0 or \x. x are suitable proofs) but a perfectly sensible construction, about which we might perhaps wish to prove interesting theorems.

In my limited experience, it seems that the most common answer is to regard as propositions those types that are subsingletons, a.k.a. proof-irrelevant, a.k.a. (-1)-truncated or h-level 1 (in the language of homotopy type theory). But in that case, the quantifier “there exists” has to be interpreted not by a -type but by a squashed version of it. Then the axiom of choice is no longer a theorem and can be false, while Church’s Law would be (where denotes a squash type) and can be true (as it is in the effective topos). (Please correct me if my understanding of any of this is wrong.)

Since in this post you say that AC is a theorem and CL is false, using the non-squashed versions of both, I gather that this is not the meaning of “proposition” you prefer. So what, for you, makes a type into a proposition? Is it just the intent to regard it as such?

On the other hand, if we can safely add a “quote” function to intensional type theory, then we can distinguish between the two sorts, and then we can (hopefully) prove that quicksort is efficient under a chosen evaluation scheme. We could still perhaps keep a notion of extensional equality for functions as equality-of-function-application — not as convenient, maybe, but not necessarily impossible.

Why does abandoning this idea in favor of e.g. extensional type theory trouble me? Because then, if we have a proof the correctness of our tree implementation in (dependent type theory based) TheoremProver, and we want to prove that it also has the right complexity guarantees, then it seems we have two choices: 1. analyze the complexity outside of TheoremProver or 2. build a new theory of computation within TheoremProver and rewrite our tree in that embedded language. Certainly (2) works, but then is there a strong reason to prefer TheoremProver to e.g. HOL? (perhaps an affirmative answer to that question would be comforting.)