Discussion of Homotopy Type Theory and Univalent Foundations
 help / color / mirror / Atom feed
From: Jon Sterling <jon@jonmsterling.com>
To: Michael Shulman <shulman@sandiego.edu>
Cc: Thorsten Altenkirch <Thorsten.Altenkirch@nottingham.ac.uk>,
	"andrej.bauer" <andrej.bauer@andrej.com>,
	Homotopy Type Theory <homotopytypetheory@googlegroups.com>
Subject: Re: [HoTT] Question about the formal rules of cohesive homotopy type theory
Date: Fri, 18 Nov 2022 11:38:39 -0500	[thread overview]
Message-ID: <19FCB983-3890-4113-9DD6-A76C2AFD8268@jonmsterling.com> (raw)
In-Reply-To: <CADYavpxMB=1kSPQM-OmSV_a9EauGmz7Gr-U3L=qfLCqsgzOnZQ@mail.gmail.com>

Hi Mike,

Thanks for this! I think we are getting a lot closer.

On 18 Nov 2022, at 11:25, Michael Shulman wrote:

> In general, I feel like we are still talking past each other.  Maybe the
> problem is that I still haven't found the words that will communicate my
> point to you.  I was trying to say that it isn't the word "admissible" that
> matters, but there are real mathematical questions going on whatever words
> you use to talk about them.
>
> Last summer when I was explaining something about HOTT to a group that I
> think included you, I used the phrase "admissible" for a certain equality,
> and we got into a bit of this discussion.  But I felt like we agreed in the
> end that what I meant was "a rule that doesn't have to get used explicitly
> by the conversion-checker", and that it was useful to distinguish such
> things whatever we call them.  That's what I was trying to get at with
> "rules that hold in all models and can be made to hold in a particular
> presentation of the free model without being given explicitly as generating
> operations/equalities".
>
> Similarly, I don't think the implicitness or explicitness of substitutions
> in the syntax is what's crucial.  If you formulate substitutions
> implicitly, then the statement you want is that substitution can be defined
> as an "admissible" operation on the syntax.  If you formulate substitutions
> explicitly, then the statement you want is that substitutions can be
> eliminated by a computation.  Isn't this what you mean by "The equational
> theory of substitution in this situation (particularly, how to commute
> substitutions past the modal forms) is the hard part"?  You don't just want
> an equational theory for substitution -- the equations in an equational
> theory are undirected -- but some kind of rewriting system that tells you
> how to push a substitution inside the modal forms.  Whether the
> substitutions are part of the syntax or not isn't the point.
>

I agree with a lot of what you have written here, but maybe not all of it. Let me put it my own way, which is probably similar to what you are getting at --- I see deciding the equational theory of substitution as a special case of deciding the rest of the equational theory. To me, it is basically useless to have a decision procedure for "reducing substitutions but not any other computations (like beta laws, etc.)". To put it another way, if I don't have an algorithm for full normalization (or at least deciding def.eq.), I really couldn't care less if I have an algorithm for reducing substitutions.

Regarding things that exist in the syntax but not necessarily in all models, this is indeed the point of admissibility and it's really really important! It just so happens, however, that substitutions are the main example of something that is both admissible **and** exists in all reasonable models. Even in weak models, we have substitution up to isomorphism --- and no existing solution to the Seely substitution coherence problem works by saying "Well, substitution is admissible, so we don't need it in the model anyway". So the one place to look for an example of substitution-admissibility being important in type theory is actually a non-example.

Not all admissible rules are as useless as this! To the contrary, there ARE very important examples of different admissible rules that must not be derivable unless we wish to degenerate the theory; the main examples that have practical import are injectivity laws, which allow you to deterministically reduce complex equality problems to simpler ones; without these, elaboration and type checking would be essentially impossible (whereas elaboration and typechecking are completely insensitive to the question of whether substitution is admissible). Injectivity of type constructors is the main example of an important admissible rule, but there are many more examples (and I expect, based on our conversations about HOTT over the summer) that there will be a lot more interesting and important ones to discover in the coming years.

So in case it clarifies me, I think admissibility is extremely important and it is, in some sense, the main topic that people like me study. My experience has led me, however, to make a distinction between admissibilities that matter (like injectivity laws) and ones that do not matter at all (like substitution). Nonetheless, there are many roads to the same idea, and the study of type theory and logic in terms of admissible substitutions has been (and remains) an extremely reliable and effective way to obtain well-behaved theories. All I am doing is trying to tease out which parts of this process were essential, and which parts were incidental.

Best,
Jon

-- 
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/HomotopyTypeTheory/19FCB983-3890-4113-9DD6-A76C2AFD8268%40jonmsterling.com.

  reply	other threads:[~2022-11-18 16:38 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-11 22:53 Madeleine Birchfield
2022-11-11 23:47 ` Michael Shulman
2022-11-15 22:38 ` andrej.bauer
2022-11-16  9:52   ` 'Thorsten Altenkirch' via Homotopy Type Theory
2022-11-17 13:36     ` Jon Sterling
2022-11-18  2:35       ` Michael Shulman
2022-11-18  6:19         ` Tom Hirschowitz
2022-11-18 10:58         ` Jon Sterling
2022-11-18 16:16           ` Michael Shulman
2022-11-18 16:22             ` Jon Sterling
2022-11-18 11:35         ` 'Thorsten Altenkirch' via Homotopy Type Theory
2022-11-18 12:47         ` Jon Sterling
2022-11-18 13:05           ` Jon Sterling
2022-11-18 16:25             ` Michael Shulman
2022-11-18 16:38               ` Jon Sterling [this message]
2022-11-18 16:56                 ` Michael Shulman
2022-11-18 16:59                   ` Jon Sterling
2022-11-18 17:14                     ` Michael Shulman
2022-12-01 14:40                       ` Andreas Nuyts
2022-12-01 15:54                         ` Jon Sterling
2022-12-01 15:57                           ` Andreas Nuyts
2022-12-01 16:09                             ` Andreas Nuyts
2022-12-01 18:00                         ` Michael Shulman
2022-11-18 14:21     ` andrej.bauer

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=19FCB983-3890-4113-9DD6-A76C2AFD8268@jonmsterling.com \
    --to=jon@jonmsterling.com \
    --cc=Thorsten.Altenkirch@nottingham.ac.uk \
    --cc=andrej.bauer@andrej.com \
    --cc=homotopytypetheory@googlegroups.com \
    --cc=shulman@sandiego.edu \
    /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).