Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Nicolai Kraus <nicola...@gmail.com>
To: "Joyal, André" <"joyal..."@uqam.ca>,
	"Thomas Streicher" <"stre..."@mathematik.tu-darmstadt.de>
Cc: David Roberts <drober...@gmail.com>,
	Thorsten Altenkirch <Thorsten....@nottingham.ac.uk>,
	Michael Shulman <shu...@sandiego.edu>,
	Steve Awodey <awo...@cmu.edu>,
	"homotopyt...@googlegroups.com" <homotopyt...@googlegroups.com>
Subject: Re: [HoTT] Identity versus equality
Date: Sun, 10 May 2020 17:51:26 +0100	[thread overview]
Message-ID: <bb28fb70-88e5-ea38-9550-f7f952d76b62@gmail.com> (raw)
In-Reply-To: <8C57894C7413F04A98DDF5629FEC90B1652F563A@Pli.gst.uqam.ca>

Dear André and everyone,

I feel it's worth pointing out that there are two strategies to express 
"everyday mathematics" in HoTT. In CS-speak, they would probably be 
called "shallow embedding" and "deep embedding". Shallow embedding is 
the "HoTT style", deep embedding is the "pre-HoTT type theory style". 
Shallow means that one uses that the host language shares structure with 
the object one wants to define, while deep means one doesn't. To explain 
what I mean, let's look at the type theoretic definition of a group (a 
1-group, not a higher group).

Definition using deep embedding: A group is a tuple 
(X,h,e,o,i,assoc,...), where
   X : Type     -- carrier
   h : is-0-truncated(X)     -- carrier is set
   e : X   -- unit
   o : X * X -> X     -- composition
   i : X -> X     -- inverses
   assoc : (h o g) o f = h o (g o f)
   ... [and so on]

Definition using shallow embedding: A group is a pointed connected 1-type.

Fortunately, these definitions are equivalent (via the Eilenberg-McLan 
spaces construction). But they behave differently when we want to work 
with them or change them. It's easy to change the second definition to 
define infinity groups instead of 1-groups (see e.g. arXiv:1802.04315 , 
arXiv:1805.02069, and Ulrik's comment). But it's unclear whether there 
is a nice way for the first definition. The second definition has better 
computational properties than the first.

When you say this:

 > But I find it frustrating that I cant do my everyday mathematics with it.
 > For example, I cannot  say
 >
 > (1) Let X:\Delta^{op}---->Type be a simplicial type;

You are referring to shallow embedding. In everyday mathematics, you 
don't say (1) either. You probably say (1) with "Type" replaced by "Set" 
or by "simplicial set". Both of these can be expressed straightforwardly 
in type theory using only (h-)sets (i.e. embedding deeply).

We strive to use shallow embedding as often as possible for the reasons 
in the above example. But let's assume that we *can* say (1) in HoTT, 
using "Type", because we find some encoding that we're reasonably happy 
with; there's a question which I've asked myself before:

Will we not destroy the advantages of deep (over shallow) embedding if 
we fall back to encodings (and thus destroy the main selling point of 
HoTT)? For me, the justification of still using deep embedding is that 
statements using encodings (e.g. "the universe is a higher category) 
might still imply statements which don't use encodings and are 
interesting. However, if we want to develop a theory of certain higher 
structures for it's own sake, then it's not so clear to me whether it's 
really better to use the HoTT-style deep embedding.

Kind regards,
Nicolai


On 09/05/2020 21:18, Joyal, André wrote:
> Dear Thomas,
>
> You wrote
>
> <<In my opinion the currenrly implemented type theories are essentially
> for proving and not for computing.
> But if you haven't mechanized PART of equational reasoning it would be
> much much more painful than it still is.
> But that is "only" a pragmatic issue.>>
>
> Type  theory has very nice features. I wish they could be preserved and developped further.
> But I find it frustrating that I cant do my everyday mathematics with it.
> For example, I cannot  say
>
> (1) Let X:\Delta^{op}---->Type be a simplicial type;
> (2) Let G be a type equipped with a group structure;
> (3) Let BG be the classifying space of a group G;
> (4) Let Gr be the category of groups;
> (5) Let SType be the category of simplical types.
> (6) Let Map(X,Y) be the simplicial types of maps X--->Y
> between two simplicial types X and Y.
>
> It is crucial to have (1)
> For example, a group could be defined to
> be a simplicial object satisfying the Segal conditions.
> The classifying space of a group is the colimit of this simplicial object.
> The category of groups can be defined to be
> a simplicial objects satisfiying the Rezk conditions (a complete Segal space).
>
> Is there some aspects of type theory that we may give up as a price
> for solving these problems ?
>
>
> Best,
> André
>
> ________________________________________
> From: Thomas Streicher [stre...@mathematik.tu-darmstadt.de]
> Sent: Saturday, May 09, 2020 2:43 PM
> To: Joyal, André
> Cc: David Roberts; Thorsten Altenkirch; Michael Shulman; Steve Awodey; homotopyt...@googlegroups.com
> Subject: Re: [HoTT] Identity versus equality
>
> Dear Andr'e,
>
>> By the way, if type theory is not very effective in practice, why do we insist that it should always compute?
>> The dream of a formal system in which every proof leads to an actual computation may be far off.
>> Not that we should abandon it, new discoveries are always possible.
>> Is there a version of type theory for proving and verifying, less
>> for computing?
> In my opinion the currenrly implemented type theories are essentially
> for proving and not for computing.
> But if you haven't mechanized PART of equational reasoning it would be
> much much more painful than it still is.
> But that is "only" a pragmatic issue.
>
>> The notations of type theory are very useful in homotopy theory.
>> But the absence of simplicial types is a serious obstacle to applications.
> In cubical type theory they sort of live well with cubes not being
> fibrant... They have them as pretypes. But maybe I misunderstand...
>
> Thomas
>


  parent reply	other threads:[~2020-05-10 16:51 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-05-05  8:47 Ansten Mørch Klev
2020-05-06 16:02 ` [HoTT] " Joyal, André
2020-05-06 19:01   ` Steve Awodey
2020-05-06 19:18     ` Michael Shulman
2020-05-06 19:31       ` Steve Awodey
2020-05-06 20:30         ` Joyal, André
2020-05-06 22:52         ` Thorsten Altenkirch
2020-05-06 22:54       ` Thorsten Altenkirch
2020-05-06 23:29         ` Joyal, André
2020-05-07  6:11           ` Egbert Rijke
2020-05-07  6:58           ` Thorsten Altenkirch
2020-05-07  9:04             ` Ansten Mørch Klev
2020-05-07 10:09             ` Thomas Streicher
2020-05-07 16:13               ` Joyal, André
2020-05-07 21:41                 ` David Roberts
2020-05-07 23:43                   ` Joyal, André
2020-05-07 23:56                     ` David Roberts
2020-05-08  6:40                       ` Thomas Streicher
2020-05-08 21:06                         ` Joyal, André
2020-05-08 23:44                           ` Steve Awodey
2020-05-09  2:46                             ` Joyal, André
2020-05-09  3:09                               ` Jon Sterling
     [not found]                             ` <CADZEZBY+3z6nrRwsx9p-HqYuTxAnwMUHv7JasHy8aoy1oaGPcw@mail.gmail.com>
2020-05-09  2:50                               ` Steve Awodey
2020-05-09  8:28                           ` Thomas Streicher
2020-05-09 15:53                             ` Joyal, André
2020-05-09 18:43                               ` Thomas Streicher
2020-05-09 20:18                                 ` Joyal, André
2020-05-09 21:27                                   ` Jon Sterling
2020-05-10  2:19                                     ` Joyal, André
2020-05-10  3:04                                       ` Jon Sterling
2020-05-10  9:09                                         ` Thomas Streicher
2020-05-10 11:59                                           ` Thorsten Altenkirch
2020-05-10 11:46                                     ` Thorsten Altenkirch
2020-05-10 14:01                                       ` Michael Shulman
2020-05-10 14:20                                         ` Nicolai Kraus
2020-05-10 14:34                                           ` Michael Shulman
2020-05-10 14:52                                             ` Nicolai Kraus
2020-05-10 15:16                                               ` Michael Shulman
2020-05-10 15:23                                                 ` Nicolai Kraus
2020-05-10 16:13                                                   ` Nicolai Kraus
2020-05-10 16:28                                                     ` Michael Shulman
2020-05-10 18:18                                                       ` Nicolai Kraus
2020-05-10 19:15                                             ` Thorsten Altenkirch
2020-05-10 19:20                                         ` Thorsten Altenkirch
2020-05-10 12:53                                   ` Ulrik Buchholtz
2020-05-10 14:01                                     ` Michael Shulman
2020-05-10 14:27                                       ` Nicolai Kraus
2020-05-10 15:35                                         ` Ulrik Buchholtz
2020-05-10 16:30                                           ` Michael Shulman
2020-05-10 18:56                                           ` Nicolai Kraus
2020-05-10 18:04                                     ` Joyal, André
2020-05-11  7:33                                       ` Thomas Streicher
2020-05-11 14:54                                         ` Joyal, André
2020-05-11 16:37                                           ` stre...
2020-05-11 16:42                                             ` Michael Shulman
2020-05-11 17:27                                               ` Thomas Streicher
2020-05-10 16:51                                   ` Nicolai Kraus [this message]
2020-05-10 18:57                                     ` Michael Shulman
2020-05-10 19:18                                     ` Nicolai Kraus
2020-05-10 20:22                                       ` Michael Shulman
2020-05-10 22:08                                         ` Joyal, André

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=bb28fb70-88e5-ea38-9550-f7f952d76b62@gmail.com \
    --to="nicola..."@gmail.com \
    --cc="Thorsten...."@nottingham.ac.uk \
    --cc="awo..."@cmu.edu \
    --cc="drober..."@gmail.com \
    --cc="homotopyt..."@googlegroups.com \
    --cc="joyal..."@uqam.ca \
    --cc="shu..."@sandiego.edu \
    --cc="stre..."@mathematik.tu-darmstadt.de \
    /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).