Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Matt Oliveri <atmacen@gmail.com>
To: Homotopy Type Theory <HomotopyTypeTheory@googlegroups.com>
Subject: [HoTT] Re: Why do we need judgmental equality?
Date: Sun, 10 Feb 2019 22:51:29 -0800 (PST)	[thread overview]
Message-ID: <0a575642-04bb-4b8a-b0d9-c609f7f125dc@googlegroups.com> (raw)
In-Reply-To: <c89f0e42-4797-4573-a5d8-35cce6c5efa5@googlegroups.com>


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

On Saturday, February 9, 2019 at 6:53:15 AM UTC-5, Felix Rech wrote:
>
> Judgmental equality cannot be taken as assumptions. If one wants to use 
> judgmental equalities then one has to give concrete definitions that 
> satisfy those equalities and cannot hide the definition details. This makes 
> it impossible to change definitions later on without breaking constructions 
> that depend on them.
>

I worry that this will indeed be a modularity problem in practice. You 
generally can't specify behavior strictly at the interface between 
subsystems. Semantic purists would point out that such an interface 
wouldn't make sense anyway, unless the subsystem's type is an hset, and you 
use paths. In general, you should specify a bunch of coherences. Aside from 
being way harder though, we don't know how to do it in general, because of 
the infinite object problem.

With a 2-level theory, you could at least have second-class module 
signatures with strict equality.

In nontrivial definitions, judgmental equalities seem more arbitrary than 
> natural. If we define addition of natural numbers for example then we can 
> choose between x + 0 = x and 0 + x = x as judgmental equality but we cannot 
> have both. This makes it hard to find the right definitions and to predict 
> their behavior.
> Another motivation was of course that it would simplify the implementation 
> of proof checkers and parts of the metatheory.
>

This problem is solved by the special case of 2-level theories where strict 
equality is reflective (like extensional type theory (ETT)). What this does 
for you in practice is that you never have to see coercions between e.g. 
types (F (x + 0)) and (F (0 + x)), since they can be proven judgmentally 
equal by induction. (What I mean is that there's no record in terms of 
rewriting with nat equality. Not that all such reasoning can be done 
automatically. (It presumably is easy to automate both plus-zero rewrites 
though.))

Without reflective equality, strict equality doesn't seem to provide any 
benefit over paths in this case, because you need a coercion, and paths 
between nats are already unique.

-- 
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 HomotopyTypeTheory+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

  parent reply	other threads:[~2019-02-11  6:51 UTC|newest]

Thread overview: 71+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-01-30 11:54 [HoTT] " Felix Rech
2019-02-05 23:00 ` [HoTT] " Matt Oliveri
2019-02-06  4:13   ` Anders Mörtberg
2019-02-09 11:55     ` Felix Rech
2019-02-16 15:59     ` Thorsten Altenkirch
2019-02-17  1:25       ` Michael Shulman
2019-02-17  7:56         ` Thorsten Altenkirch
2019-02-17  9:14           ` Matt Oliveri
2019-02-17  9:18           ` Michael Shulman
2019-02-17 10:52             ` Thorsten Altenkirch
2019-02-17 11:35               ` streicher
2019-02-17 11:44                 ` Thorsten Altenkirch
2019-02-17 14:24                   ` Bas Spitters
2019-02-17 19:36                   ` Thomas Streicher
2019-02-17 21:41                     ` Thorsten Altenkirch
2019-02-17 12:08             ` Matt Oliveri
2019-02-17 12:13               ` Matt Oliveri
2019-02-20  0:22               ` Michael Shulman
2019-02-17 14:22           ` [Agda] " Andreas Abel
2019-02-17  9:05         ` Matt Oliveri
2019-02-17 13:29         ` Nicolai Kraus
2019-02-08 21:19 ` Martín Hötzel Escardó
2019-02-08 23:31   ` Valery Isaev
2019-02-09  1:41     ` Nicolai Kraus
2019-02-09  8:04       ` Valery Isaev
2019-02-09  1:58     ` Jon Sterling
2019-02-09  8:16       ` Valery Isaev
2019-02-09  1:30   ` Nicolai Kraus
2019-02-09 11:38   ` Thomas Streicher
2019-02-09 13:29     ` Thorsten Altenkirch
2019-02-09 13:40       ` Théo Winterhalter
2019-02-09 11:57   ` Felix Rech
2019-02-09 12:39     ` Martín Hötzel Escardó
2019-02-11  6:58     ` Matt Oliveri
2019-02-18 17:37   ` Martín Hötzel Escardó
2019-02-18 19:22     ` Licata, Dan
2019-02-18 20:23       ` Martín Hötzel Escardó
2019-02-09 11:53 ` Felix Rech
2019-02-09 14:04   ` Nicolai Kraus
2019-02-09 14:26     ` Gabriel Scherer
2019-02-09 14:44     ` Jon Sterling
2019-02-09 20:34       ` Michael Shulman
2019-02-11 12:17         ` Matt Oliveri
2019-02-11 13:04           ` Michael Shulman
2019-02-11 15:09             ` Matt Oliveri
2019-02-11 17:20               ` Michael Shulman
2019-02-11 18:17                 ` Thorsten Altenkirch
2019-02-11 18:45                   ` Alexander Kurz
2019-02-11 22:58                     ` Thorsten Altenkirch
2019-02-12  2:09                       ` Jacques Carette
2019-02-12 11:03                   ` Matt Oliveri
2019-02-12 15:36                     ` Thorsten Altenkirch
2019-02-12 15:59                       ` Matt Oliveri
2019-02-11 19:27                 ` Matt Oliveri
2019-02-11 21:49                   ` Michael Shulman
2019-02-12  9:01                     ` Matt Oliveri
2019-02-12 17:54                       ` Michael Shulman
2019-02-13  6:37                         ` Matt Oliveri
2019-02-13 10:01                           ` Ansten Mørch Klev
2019-02-11 20:11                 ` Matt Oliveri
2019-02-11  8:23       ` Matt Oliveri
2019-02-11 13:03         ` Jon Sterling
2019-02-11 13:22           ` Matt Oliveri
2019-02-11 13:37             ` Jon Sterling
2019-02-11  6:51   ` Matt Oliveri [this message]
2019-02-09 12:30 ` [HoTT] " Thorsten Altenkirch
2019-02-11  7:01   ` Matt Oliveri
2019-02-11  8:04     ` Valery Isaev
2019-02-11  8:28       ` Matt Oliveri
2019-02-11  8:37         ` Matt Oliveri
2019-02-11  9:32           ` Rafaël Bocquet

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=0a575642-04bb-4b8a-b0d9-c609f7f125dc@googlegroups.com \
    --to=atmacen@gmail.com \
    --cc=HomotopyTypeTheory@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).