From: Matt Oliveri <atm...@gmail.com>
To: Homotopy Type Theory <HomotopyT...@googlegroups.com>
Subject: Re: [HoTT] Re: cubical type theory with UIP
Date: Tue, 1 Aug 2017 14:27:42 -0700 (PDT) [thread overview]
Message-ID: <8e016296-dcb6-4596-af91-255f564fad2b@googlegroups.com> (raw)
In-Reply-To: <CAOvivQykPkQePQRELFbsLJSt9kVentz-S06m=qmw-gUz1Tc3fw@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 1767 bytes --]
On Monday, July 31, 2017 at 11:51:18 AM UTC-4, Michael Shulman wrote:
>
> I'm not quite sure what a "strict proposition" is, but if you mean
> having a type of propositions that doesn't include all of them, then
> the reason that's not enough for me is that frequently in univalent
> type theory we encounter types that we *prove* to be propositions even
> though they are not "given as such", such as "being contractible" and
> "being a proposition", and this is responsible for a significant
> amount of the unique flavor and usefulness of univalent type theory.
>
> For semantic reasons I wouldn't want to use intuitionistic set theory,
> because it doesn't naturally occur as the internal language of
> categories. You can perform contortions to model it therein, but that
> involves interpreting it into type theory rather than the other way
> around. I don't know what you mean by "somehow clean it up into a
> type system", but if you can do that cleaning up and obtain a type
> theory (a "formal type theory" in Bob Harper's sense, not a
> "computational type theory", i.e. one that is inductively generated by
> rules rather than assigning types to untyped terms in an "intended
> semantics"), then I'd like to see it.
>
I'm thinking it would look a lot like OTT, but with unique choice for
strict props. Not all subsingletons are strict props, so they would not be
subject to propositional extensionality. So this is apparently not what you
want.
However, I'm not very confident about all that. I wouldn't be that
surprised if it worked out differently. (In particular, something OTT-like,
but with unique choice may not even make sense.) But I don't think it'll be
what you want, in any case. I've lost interest in that approach.
[-- Attachment #1.2: Type: text/html, Size: 2104 bytes --]
next prev parent reply other threads:[~2017-08-01 21:27 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-23 22:54 Michael Shulman
2017-07-29 1:47 ` Matt Oliveri
2017-07-29 2:25 ` [HoTT] " Jon Sterling
2017-07-29 7:29 ` Matt Oliveri
2017-07-29 6:19 ` Michael Shulman
2017-07-29 7:23 ` Matt Oliveri
2017-07-29 8:07 ` Michael Shulman
2017-07-29 10:19 ` Matt Oliveri
2017-07-29 11:08 ` Matt Oliveri
2017-07-29 21:19 ` Michael Shulman
[not found] ` <8f052071-09e0-74db-13dc-7f76bc71e374@cs.bham.ac.uk>
2017-07-31 3:49 ` Matt Oliveri
2017-07-31 15:50 ` Michael Shulman
2017-07-31 17:36 ` Matt Oliveri
2017-08-01 9:14 ` Neelakantan Krishnaswami
2017-08-01 9:20 ` Michael Shulman
2017-08-01 9:34 ` James Cheney
2017-08-01 16:26 ` Michael Shulman
2017-08-01 21:27 ` Matt Oliveri [this message]
2017-07-31 4:19 ` Matt Oliveri
2017-08-02 9:40 ` [HoTT] " Andrea Vezzosi
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=8e016296-dcb6-4596-af91-255f564fad2b@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).