Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Michael Shulman <shu...@sandiego.edu>
To: Martin Escardo <escardo...@googlemail.com>
Cc: "HomotopyT...@googlegroups.com" <HomotopyT...@googlegroups.com>
Subject: Re: [HoTT] Conjecture
Date: Fri, 7 Apr 2017 10:11:46 -0700	[thread overview]
Message-ID: <CAOvivQwpFWMz7tqf-y4=ZZV_tQLr=MQK5HYvQUU1KDmu-=NsCw@mail.gmail.com> (raw)
In-Reply-To: <4c10260c-cde9-a1e9-8ed1-f8b19610e059@googlemail.com>

On Fri, Apr 7, 2017 at 2:49 AM, 'Martin Escardo' via Homotopy Type
Theory <HomotopyT...@googlegroups.com> wrote:
> (1) Indeed, I do like to think of the fragment of univalent type
> theory consisting of function extensionality + proposition
> extensionality + propositional truncation as essentially the same
> thing as topos logic, provided we have propositional resizing. (But,
> as discussed, much can be done without propositional resizing (but not
> all), and one way of looking at HIT's is as a mechanism to avoid
> resizing.)

I would say that to really be talking about (elementary) topos logic,
one should also do without universes other than hProp.  Of course,
elementary 1-toposes also validate UIP.

If we also omit hProp and propositional resizing, but include
nonrecursive HITs as well as ordinary inductive types, then it ought
to be basically Pi-W-pretopos logic; right?

> This is good: this fragment leaves us in familiar territory.
>
> (2) I don't see univalent type theory as simply the extension of type
> theory with univalence (and hence function and proposition
> extensionality). Before we extend dependent type theory with any
> axiom, we can start to think "univalently".
>
> In particular, the notions of h-level, proposition, contractibility,
> equivalence, the distinction of existence as proposition or structure,
> so as to be able to define e.g. embeddings, surjections, and many
> others correctly, can be formulated and understood before we bring
> univalence.
>
> In this way "univalent type theory" is a different way to understand
> good old type theory. Of course, with univalence we get more, and what
> you are saying, and I don't disagree fundamentally, is that this
> "more" are types of higher h-level and theorems and constructions with
> them (such as the type of categories, if we want to avoid homotopy in
> the discussion).
>
> Although we don't use univalence in our paper, we formulate our
> notions in the light of this new, alternative understanding of type
> theory.
>
> One example, already mentioned in the above answer to Jon, is
> something that kept Cory and I working for an afternoon, but perhaps
> is not adequately emphasized in the paper.
>
> In topos logic, you define (for the dominance of all propositions)
>
>   Lift(X) = { A:X->Omega | (exists(x:X), A x) &
>                            forall(x,y:X), A x -> A y -> x = y }
>
> If we want, in univalent type theory, this to work for types of higher
> h-levels, how should we define this?
>
> The above definition works well and can be kept as it is if X is a
> set. To generalize it to types of higher levels, we need two
> modifications:
>
>   (i)  Change Omega to the universe U.
>   (ii) Reformulate the condition on A as isProp(Sigma(x:X), A x).
>
> When X is a set, the reformulation (i)-(ii) makes no
> difference. However, in the general case, it is (i) and (ii) that give
> the right definition. For instance, with the right definition, we
> always get an embedding X->Lift X, whereas if we had taken the
> original topos-theoretic version of Lift, then Lift S^1 would be a
> singleton and hence wouldn't embed S^1. We would get the wrong notion
> of partial function.
>
> Thus, although we haven't used univalence, we took care of formulating
> the notions so that they are not restricted to the realm of sets, and
> in this sense what we are doing can be considered as univalent type
> theory.
>
> (3) We should have cited Andrej's and Bernhard's references below, and
> we will (and many other things, to reflect the amount of work done
> about this in the context of topos theory). Of course we are aware of
> them, but thanks for mentioning them in this list!
>
> (4) A last point is that, as opposed to most of the work in the topos
> literature for dominances in realizability toposes as in (3), we
> deliberately don't use Markov's principle or countable choice in our
> internal development of computability in univalent type theory
> (Section 3 of the paper). Moreover, we are *not* looking at synthetic
> computability. We are looking at plain computability.
>
> Best,
> Martin
>
>
> On 06/04/17 12:52, Thomas Streicher wrote:
>>> This looks like a very interesting paper, thank you for sharing. I look
>>> forward to reading it in more detail.
>>>
>>> I am curious, does this development use univalence except to establish
>>> functional extensionality and propositional extensionality? The reason I
>>> ask is, I wonder if it is possible to do a similar development of
>>> computability theory in extensional type theory and get analogous
>>> results. Additionally, I am curious whether you have found cases in
>>> which univalence clarifies or sharpens this development, since I'm
>>> trying to keep track of interesting use-cases of univalence.
>>
>> For synthetic domain theory a formulation in extensional type theory
>> has been given in
>>
>> MR1694130 (2000f:68069)
>> Reus, Bernhard; Streicher, Thomas
>> General synthetic domain theory — a logical approach. (English summary)
>> Math. Structures Comput. Sci. 9 (1999), no. 2, 177–223.
>>
>> There is no need whatsoever to use univalence or something like that.
>> The only benefit would be to solve domain equations up to equality
>> which even computer scientists find unnecessary (for good reasons).
>>
>> Andrej Bauer has written on Synthetic Recursion Theory, see
>> math.andrej.com/data/synthetic.pdf.
>>
>> So I tend to the opinion that theer can't be an intrinsic use of
>> Univalence or HITs. But if there is I am curious to learn which one!
>>
>> Thomas
>>
>
> --
> Martin Escardo
> http://www.cs.bham.ac.uk/~mhe
>
> --
> You received this message because you are subscribed to the Google Groups "Homotopy Type Theory" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to HomotopyTypeThe...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

  reply	other threads:[~2017-04-07 17:12 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-27 21:57 Conjecture Martin Escardo
2017-03-29 21:08 ` [HoTT] Conjecture Nicolai Kraus
2017-03-29 22:05   ` Martin Escardo
2017-03-30 10:59     ` Michael Shulman
2017-03-30 19:22       ` Egbert Rijke
2017-03-30 23:02         ` Nicolai Kraus
2017-03-30 22:49     ` Nicolai Kraus
2017-03-31 16:09       ` Martin Escardo
2017-04-05 19:37         ` Martin Escardo
2017-04-06  0:23           ` Jon Sterling
2017-04-06  5:55             ` Martin Escardo
2017-04-06 12:40               ` Vladimir Voevodsky
2017-04-06 13:50                 ` Martin Escardo
     [not found]                   ` <81c0782f-9287-4111-a4f1-01cb9c87c7e8@cs.bham.ac.uk>
2017-04-06 16:09                     ` Martin Escardo
2017-04-06 11:52             ` Thomas Streicher
2017-04-07  9:49               ` Martin Escardo
2017-04-07 17:11                 ` Michael Shulman [this message]
2017-04-07 18:10                   ` Martin Escardo
2017-04-03  0:35 ` Conjecture Daniel R. Grayson
2017-04-03  2:20   ` [HoTT] Conjecture Favonia
2017-04-03  9:56   ` Nicolai Kraus
2017-04-03 11:50     ` Daniel R. Grayson

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='CAOvivQwpFWMz7tqf-y4=ZZV_tQLr=MQK5HYvQUU1KDmu-=NsCw@mail.gmail.com' \
    --to="shu..."@sandiego.edu \
    --cc="HomotopyT..."@googlegroups.com \
    --cc="escardo..."@googlemail.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).