Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Matt Oliveri <atm...@gmail.com>
To: Homotopy Type Theory <HomotopyT...@googlegroups.com>
Subject: Re: [HoTT] Impredicative set + function extensionality + proof irrelevance consistent?
Date: Mon, 18 Dec 2017 03:17:46 -0800 (PST)	[thread overview]
Message-ID: <be3fccca-0de4-48cf-a5b3-b2fb28997afe@googlegroups.com> (raw)
In-Reply-To: <A88995F3-43D1-43A2-A448-3C6EFC422D8E@exmail.nottingham.ac.uk>


[-- Attachment #1.1: Type: text/plain, Size: 2762 bytes --]

On Monday, December 18, 2017 at 5:10:15 AM UTC-5, Thorsten Altenkirch wrote:
>
>
> With static props, you can't prove unique choice, but it may be consistent 
> as an additional primitive, or you can ensure in some other way that you 
> have a subobject classifier.
>
>  
>
> Yes, indeed. However, adding postulates to Type Theory is just a stop gap 
> measure because you still don’t have a computational interpretation. While 
> we have a computational interpretation for most of HoTT, namely cubical 
> type theory ala Coquand et al, one might hope that there is a simpler way 
> to deal with the set level fragment of HoTT.
>

I suspect one could also come up with a type system with a computational 
interpretation that has static props and unique choice. I was counting this 
possibility too as an additional primitive.


> The static props approach can also be used in a dependent type system, 
> along with unique choice or equivalent. (To say nothing of whether that's a 
> natural kind of system.)
>
> In a dependent type system, a type of static props may or may not be a 
> universe.
>
>  
>
> What do you mean by “is a universe” here?
>

Just that the type of props would be one of the built-in universes, either 
Russell or Tarski-style.


> But if it is, you should at least have typal proof-irrelevance. (That is, 
> stated using equality types.)
>
> In that case, with equality reflection, you automatically get judgmental 
> proof-irrelevance. 
>
>  
>
> For equality but not for propositions in general.
>

I'm saying if you have typal proof-irrelevance and equality reflection, you 
get judgmental proof-irrelevance by reflecting the equalities between 
proofs given by typal proof-irrelevance.

 
>
> This does not necessarily mean that proofs are computationally irrelevant. 
>
>  
>
> Now I am confused: what is the difference between judgmental and 
> computational irrelevance?
>

By computationally-irrelevant proofs, I mean that terms of propositions are 
never needed when evaluating closed terms of non-proposition types. Like, 
Coq has a type of static propositions: the universe Prop. And the proofs 
are supposed to be computationally irrelevant. This is relied upon to erase 
them with program extraction. From the earlier messages about Lean, it 
sounds like Lean's proofs are also intended to be computationally 
irrelevant.

With equality reflection, irrelevance according to judgmental equality can 
be totally different from computational relevance. (Though it seems like a 
confusing and unhelpful possibility. When judgments are undecidable anyway, 
computationally irrelevant proofs can simply be removed from the term 
language entirely.)

[-- Attachment #1.2: Type: text/html, Size: 4117 bytes --]

  reply	other threads:[~2017-12-18 11:17 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-11  4:22 Kristina Sojakova
2017-12-11 11:42 ` [HoTT] " Jon Sterling
2017-12-11 12:15   ` Kristina Sojakova
2017-12-11 12:43     ` Jon Sterling
2017-12-11 14:28       ` Thomas Streicher
2017-12-11 14:32         ` Kristina Sojakova
2017-12-11 14:23 ` Thorsten Altenkirch
2017-12-12 10:15   ` Andrea Vezzosi
2017-12-12 11:03     ` Thorsten Altenkirch
2017-12-12 12:02       ` Thomas Streicher
2017-12-12 12:21         ` Thorsten Altenkirch
2017-12-12 13:17           ` Jon Sterling
2017-12-12 19:29             ` Thomas Streicher
2017-12-12 19:52               ` Martin Escardo
2017-12-12 23:14           ` Michael Shulman
2017-12-14 12:32             ` Thorsten Altenkirch
2017-12-14 18:52               ` Michael Shulman
2017-12-16 15:21                 ` Thorsten Altenkirch
2017-12-17 12:55                   ` Michael Shulman
2017-12-17 17:08                     ` Ben Sherman
2017-12-17 17:16                       ` Thorsten Altenkirch
2017-12-17 22:43                         ` Floris van Doorn
2017-12-15 17:00           ` Thomas Streicher
2017-12-17  8:47             ` Thorsten Altenkirch
2017-12-17 10:21               ` Thomas Streicher
2017-12-17 11:39                 ` Thorsten Altenkirch
2017-12-18  7:41                   ` Matt Oliveri
2017-12-18 10:00                     ` Michael Shulman
2017-12-18 11:55                       ` Matt Oliveri
2017-12-18 16:24                         ` Michael Shulman
2017-12-18 20:08                           ` Matt Oliveri
2017-12-18 10:10                     ` Thorsten Altenkirch
2017-12-18 11:17                       ` Matt Oliveri [this message]
2017-12-18 12:09                       ` Matt Oliveri
2017-12-18 11:52                   ` Thomas Streicher
2017-12-19 11:26                     ` Thorsten Altenkirch
2017-12-19 13:52                       ` Andrej Bauer
2017-12-19 14:44                         ` Thorsten Altenkirch
2017-12-19 15:31                           ` Thomas Streicher
2017-12-19 16:10                             ` Thorsten Altenkirch
2017-12-19 16:31                               ` Thomas Streicher
2017-12-19 16:37                                 ` Thorsten Altenkirch
2017-12-20 11:00                                   ` Thomas Streicher
2017-12-20 11:16                                     ` Thorsten Altenkirch
2017-12-20 11:41                                       ` Thomas Streicher
2017-12-21  0:42                                         ` Matt Oliveri
2017-12-22 11:18                                           ` Thorsten Altenkirch
2017-12-22 21:20                                             ` Martín Hötzel Escardó
2017-12-22 21:36                                               ` Martín Hötzel Escardó
2017-12-23  0:25                                               ` Matt Oliveri
2017-12-19 16:41                         ` Steve Awodey
2017-12-20  0:14                           ` Andrej Bauer
2017-12-20  3:55                             ` Steve Awodey
     [not found]       ` <fa8c0c3c-4870-4c06-fd4d-70be992d3ac0@skyskimmer.net>
2017-12-14 13:28         ` Thorsten Altenkirch

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=be3fccca-0de4-48cf-a5b3-b2fb28997afe@googlegroups.com \
    --to="atm..."@gmail.com \
    --cc="HomotopyT..."@googlegroups.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).