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 12:08:14 -0800 (PST)	[thread overview]
Message-ID: <1a2c4994-6b09-4a57-be5e-1fe0a7495e28@googlegroups.com> (raw)
In-Reply-To: <CAOvivQymw1M855_USRVyBD=ZHRSKO1kxYxURvhG9SjzMLfpsnw@mail.gmail.com>


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

Well that's true. For some reason, I was thinking equality would still be 
an ordinary type, but I guess that would be silly.

So what do you require, for HITs to "make sense", with equality being a 
static prop family? That they can provide finite colimits? Don't they do 
this, analogously to homotopy colimits in HoTT?

On Monday, December 18, 2017 at 11:25:22 AM UTC-5, Michael Shulman wrote:
>
> HITs involve equality, so if equality is a static prop, then it is 
> involved. 
>
> On Mon, Dec 18, 2017 at 3:55 AM, Matt Oliveri <atm...@gmail.com 
> <javascript:>> wrote: 
> > Oh right. Static propositions alone doesn't seem to guarantee a 
> quasitopos 
> > either. 
> > 
> > I thought HITs make sense with static props. After all, the type of 
> > propositions isn't even involved, formally. 
> > 
> > On Monday, December 18, 2017 at 5:00:51 AM UTC-5, Michael Shulman wrote: 
> >> 
> >> That seems about right to me, except that I don't know whether a 
> >> static universe of props without unique choice *actually* gives a 
> >> quasitopos.  It gives you a class of subobjects that have a classifer, 
> >> which looks kind of like a quasitopos, but can we prove that they are 
> >> actually the strong/regular monos as in a quasitopos?  And a 
> >> quasitopos also has finite colimits; do HITs make sense with a static 
> >> Prop? 
> >> 
> >> On Sun, Dec 17, 2017 at 11:41 PM, Matt Oliveri <atm...@gmail.com> 
> wrote: 
> >> > Hello. I'd like to see if I have the situation straight: 
> >> > 
> >> > For presenting a topos as a type system, there are expected to be (at 
> >> > least) 
> >> > two styles: having a type of "static" propositions, or using hprops. 
> >> > 
> >> > With hprops, you can prove unique choice, so it's always topos-like 
> >> > (pretopos?). 
> >> > 
> >> > 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. 
> >> > 
> >> > If you don't necessarily have unique choice or equivalent, you're 
> >> > dealing 
> >> > with a quasitopos, which is a more general thing. 
> >> > 
> >> > With static props and unique choice, subsingletons generally aren't 
> >> > already 
> >> > propositions, but they all correspond to a proposition stating that 
> the 
> >> > subsingleton is inhabited. Unique choice obtains the element of a 
> >> > subsingleton known to be inhabited. 
> >> > 
> >> > The usual way to present a topos as a type system is with a 
> >> > non-dependent 
> >> > type system like IHOL. This will not be able to express hprops, so 
> >> > static 
> >> > props is the way. Proofs will not be objects, so proof-irrelevance 
> >> > doesn't 
> >> > come up. 
> >> > 
> >> > 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. 
> >> > 
> >> > If it's not, proofs still aren't objects and proof-irrelevance still 
> >> > doesn't 
> >> > come up. 
> >> > 
> >> > 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. This does not necessarily mean that proofs are 
> >> > computationally irrelevant. With unique choice, they cannot be, or 
> else 
> >> > you 
> >> > lose canonicity. 
> >> > 
> >> > All OK?
>

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

  reply	other threads:[~2017-12-18 20:08 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 [this message]
2017-12-18 10:10                     ` Thorsten Altenkirch
2017-12-18 11:17                       ` Matt Oliveri
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=1a2c4994-6b09-4a57-be5e-1fe0a7495e28@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).