[Agda] [Coq-Club] Concepts within Type Theory – Re: Type Theory vs. Set Theory – Re: Why dependent type theory?

[Ken Kubota]

> Am 13.03.2020 um 17:19 schrieb Thorsten Altenkirch <Thorsten.Altenkirch at nottingham.ac.uk>:
> 
> This means that types are the result of simple operations such as lambda abstraction and lambda application (cf. wff constructions (b) and (c) at [Andrews 2002 (ISBN 1-4020-0763-9), p. 211]).
>  
> This means you have a very intensional view of Mathematics centred around encodings. I think this is misleading because Mathematics is about abstraction and abstract concepts, encodings are only coincidental.

Of course, encoding is not a self-purpose.
That all logical connectives can be defined in terms of the Sheffer stroke is coincidental and not of particular interest.
But the concept of expressiveness (reducibility) used by Andrews (and intuitively by Church) is very natural, and for good reason many mathematicians endorse these formulations of higher-order logic (Church's type theory, Andrews' Q0, Gordon's HOL), and the implementations are widely used (HOL4, HOL Light, Isabelle/HOL).
In this concept, the reduction to certain primitive symbols is very natural and reveals the inner logic of high level notions.


> Moreover, using Andrews' concept of "expressiveness" (also intuitively used by Church before), all mathematical concepts can be reduced – naturally (not like in machine language) – to a few basic notions: 
> Q0 basically has a single variable binder (lambda), two primitive symbols and two primitive types, and a single rule of inference.
> R0 has only little more (some features required for type variables, type abstraction, and dependent types).
> Both are Hilbert-style systems (operating at the object language level only).
>  
> This seems to be a view of mathematical foundations stuck in the middle of the last century.
>  
> The notion of type theory you refer to seems to intend more than just preventing (negative) self-reference.
> The univalence axiom, and the desire to „structure mathematical constructions in a reasonable way“ are motivated by philosophical or metamathematical considerations.
> These motivations have their legitimation, but shouldn’t be part of the formal language.
>  
> For this reason I already object to the Pi type (as implemented in Lean), or dependent function type, which I consider a metamathematical notion: https://groups.google.com/d/msg/metamath/Fgn0qZEzCko/bvVem1BZCQAJ <https://groups.google.com/d/msg/metamath/Fgn0qZEzCko/bvVem1BZCQAJ>
> I believe that type abstraction is fully sufficient to express what the Pi type is supposed to express.
>  
> So you are only interested in some mathematical machine code but not in the high level notions. Such a view of mathematical foundation is akin to the view some programmers had (and maybe still have) that all what matters is machine code. To the contrary you can build the same foundations on different notions of machine code. The machine code is irrelevant, all what matters are the abstractions.

It is important to distinguish two different kinds of high level notions:
Those that can be reduced naturally to primitive symbols, and those which try to express metamathematical ideas (which seems to be your notion).
The latter shouldn't be implemented as primitive symbols in the basic formal language, but should be the result of metamathematical reasoning.


>  How is type abstraction implemented in Lean, and where can I find the group definition?
>  
> I have no idea about Lean, not do I know what you mean by “type abstraction”. Polymorphism, that is constructions which are parametric in types are simply depdnent functions which have a universe as input.

Lambda as the single variable binder in formulations of higher-order logic (Church, Andrews, Gordon) traditionally can be used to bind _term variables_ only.
Type abstraction allows for binding _type variables_ also.
See https://owlofminerva.net/kubota/software-implementation-of-the-mathematical-logic-r0-available-for-download/ <https://owlofminerva.net/kubota/software-implementation-of-the-mathematical-logic-r0-available-for-download/>
and https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2018-September/msg00045.html <https://lists.cam.ac.uk/pipermail/cl-isabelle-users/2018-September/msg00045.html>
Kevin Buzzard has (like Freek Wiedijk) correctly stated that current classical higher-order logic is too weak to express certain mathematical concepts.
The main reason is that the feature of type abstraction is missing.
Gordon has suggested implementing this, but unfortunately this didn't happen in the current HOL systems (HOL4, HOL Light, Isabelle/HOL).
Andrews and Melham did some work into this direction, but used the traditional quantifiers to bind type variables, not lambda.


> Concerning constructivism (intuitionism) and intensionality, these are philosophical debates with little relevance for mathematics nowadays.
> I fully agree to Kevin Buzzard’s argument that "within mathematics departments, the prevailing view is that Hilbert won the argument 100 years ago and we have not looked back since, despite what constructivists want us to believe." – https://xenaproject.wordpress.com/2020/02/09/where-is-the-fashionable-mathematics/ <https://xenaproject.wordpress.com/2020/02/09/where-is-the-fashionable-mathematics/>
>  
> I think you miss a trick or two here. Constructivism is highly relevant, especially in computer science when we want to marry computer science with mathematical constructions. Hilbert is already dead since a while and before the first computer has been build. The world is changing, maybe philosophers and mathematicians should take notice of this.

The formulation of the formal system depends on the purpose.
Even within mathematics different formulations are required: https://groups.google.com/d/msg/metamath/Fgn0qZEzCko/lArtWey5CQAJ <https://groups.google.com/d/msg/metamath/Fgn0qZEzCko/lArtWey5CQAJ> (last part on the two-step approach).
However, from a logical (mathematical) point of view I do not see any need for constructivism.


> Cheers,
> Thorsten



Kind regards,

Ken Kubota

____________________________________________________


Ken Kubota
doi.org/10.4444/100 <https://doi.org/10.4444/100>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chalmers.se/pipermail/agda/attachments/20200314/f34d2f66/attachment.html>