<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><meta http-equiv="Content-Type" content="text/html; charset=utf-8" class=""><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">[reposting, alternate “from:” header]</div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><br class=""></div><div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class="">Hi,<div class=""><br class=""></div><div class="">I think the example below is not mathematically correct. The problem is that \cup is not the same as \sqcup. The latter is of course a coproduct in the category of sets, whereas the former is  a push-out, so a colimit of a more complicated diagram. In the line </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: AgmenaPro-Regular;"><div class="" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;">{0,1}  \cup {0,1,2,3} = {0,1,2,3}</div></div></blockquote><div class=""><br class=""></div>of course the two sets {0,1} and {0,1,2,3} are not disjoint, whereas  in the line </div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: AgmenaPro-Regular;"><div class="" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;">{true , false}  \cup {0,1,2,3} = {true,false,0,1,2,3}</div></div></blockquote><div class=""><br class=""></div><div class="">the union is actually disjoint, i.e. a coproduct. In the example with the sum, </div></div><div class=""><br class=""></div><div class=""><blockquote type="cite" class=""><div class="WordSection1" style="page: WordSection1; font-family: AgmenaPro-Regular;"><div class="" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;"><span lang="DE" class="">{0,1}  + {0,1,2,3} = {in1 0,in1 1,in2 0,in2 1,in2 2,in2 3}<o:p class=""></o:p></span></div><div class="" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;"><span lang="DE" class=""> </span></div><div class="" style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;"><span lang="DE" class="">{true , false}  + {0,1,2,3} = {in1 true,in1 false ,in2 0,in2 1,in2 2,in2 3}</span></div></div></blockquote><div class=""><br class=""></div>in the first line {0,1} is actually made disjoint from {0,1,2,3}. To turn this around, suppose you do a push-out</div><div class=""><br class=""></div><div class="">{true, false} \coprod_{0,1} {0,1,2,3}</div><div class=""><br class=""></div><div class="">where you use the maps f : {0,1} -> {true, false} and i : {0,1} ->{0,1,2,3} . Then, since f is an isomorphism, you get something isomorphic to the union. </div><div class=""><br class=""></div><div class="">So, this example doesn’t really show that \cup exposes the implementation. But part of this example becomes possible because  in sets we have naively “disembodied” elements leading to constructions of this sort…</div><div class=""><br class=""></div><div class="">…I guess, I’m just learning this stuff myself. (First post here, actually!)</div><div class=""><br class=""></div><div class="">Best,</div><div class=""><br class=""></div><div class="">—Ettore</div><div class=""><div class=""><br class=""><blockquote type="cite" class=""><div class="">On Mar 4, 2020, at 04:42, Thorsten Altenkirch <<a href="mailto:Thorsten.Altenkirch@nottingham.ac.uk" class="">Thorsten.Altenkirch@nottingham.ac.uk</a>> wrote:</div><br class="Apple-interchange-newline"><div class=""><div class="WordSection1" style="page: WordSection1; caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;"><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">First of all I don’t like the word “dependent type theory”. Dependent types are one important feature of modern Type Theory but hardly the only one.<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">To me the most important feature of Type Theory is the support of abstraction in Mathematics and computer science. Using  types instead of sets means that you can hide implementation choices which is essential if you want to build towers of abstraction. Set theory fails here badly. Just as a very simple example: in set theory you have the notion of union, so for example<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class="">{0,1}  \cup {0,1,2,3} = {0,1,2,3}<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">However, if we change the representation of the first set and use lets say {true,false} we get a different result:<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class="">{true , false}  \cup {0,1,2,3} = {true,false,0,1,2,3}<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class="">This means that \cup exposes implementation details because the results are not equivalent upto renaming. In Type Theory we have the notion of sum, sometimes called disjoint union, which is well behaved<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class=""><span lang="DE" class="">{0,1}  + {0,1,2,3} = {in1 0,in1 1,in2 0,in2 1,in2 2,in2 3}<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class=""><span lang="DE" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class=""><span lang="DE" class="">{true , false}  + {0,1,2,3} = {in1 true,in1 false ,in2 0,in2 1,in2 2,in2 3}<o:p class=""></o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span lang="DE" class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Unlike \cup, + doesn’t reveal any implementation details it is a purely structural operation. Having only structural operations means that everything you do is stable under equivalence, that is you can replace one object with another one that behaves the same. This is the essence of Voevodsky’s univalence principle.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">There are other nice aspects of Type Theory. From a constructive point of view (which should come naturally to a computer scientists) the proporsitions as types explanation provides a very natural way to obtain “logic for free” and paedagogically helpful since it reduces logical reasoning to programming.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">There are performance issues with implementations of Type Theory, however, in my experience (mainly agda) the execution of functions at compile time isn’t one of them. In my experience the main problem is to deal with a loss of sharing when handling equational constraints which can blow up the time needed for type checking. I think this is an engineering problem and there are some suggestions how to fix this.<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thorsten<o:p class=""></o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif; text-indent: 36pt;" class=""><o:p class=""> </o:p></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="margin: 0cm 0cm 0.0001pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><span class=""><o:p class=""> </o:p></span></div><div style="border-style: solid none none; border-top-width: 1pt; border-top-color: rgb(181, 196, 223); padding: 3pt 0cm 0cm;" class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><b class=""><span style="font-size: 12pt;" class="">From:<span class="Apple-converted-space"> </span></span></b><span style="font-size: 12pt;" class="">"<a href="mailto:coq-club-request@inria.fr" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq-club-request@inria.fr</a>" <<a href="mailto:coq-club-request@inria.fr" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq-club-request@inria.fr</a>> on behalf of Jason Gross <<a href="mailto:jasongross9@gmail.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">jasongross9@gmail.com</a>><br class=""><b class="">Reply to:<span class="Apple-converted-space"> </span></b>"<a href="mailto:coq-club@inria.fr" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq-club@inria.fr</a>" <<a href="mailto:coq-club@inria.fr" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq-club@inria.fr</a>><br class=""><b class="">Date:<span class="Apple-converted-space"> </span></b>Tuesday, 3 March 2020 at 19:44<br class=""><b class="">To:<span class="Apple-converted-space"> </span></b>coq-club <<a href="mailto:coq-club@inria.fr" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq-club@inria.fr</a>>, agda-list <<a href="mailto:agda@lists.chalmers.se" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">agda@lists.chalmers.se</a>>, "<a href="mailto:coq+miscellaneous@discoursemail.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq+miscellaneous@discoursemail.com</a>" <<a href="mailto:coq+miscellaneous@discoursemail.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">coq+miscellaneous@discoursemail.com</a>>, lean-user <<a href="mailto:lean-user@googlegroups.com" style="color: rgb(149, 79, 114); text-decoration: underline;" class="">lean-user@googlegroups.com</a>><br class=""><b class="">Subject:<span class="Apple-converted-space"> </span></b>[Coq-Club] Why dependent type theory?<o:p class=""></o:p></span></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I'm in the process of writing my thesis on proof assistant performance bottlenecks (with a focus on Coq), and there's a large class of performance bottlenecks that come from (mis)using the power of dependent types.  So in writing the introduction, I want to provide some justification for the design decision of using dependent types, rather than, say, set theory or classical logic (as in, e.g., Isabelle/HOL).  And the only reasons I can come up with are "it's fun" and "lots of people do it"<span class="Apple-converted-space"> </span><o:p class=""></o:p></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">So I'm asking these mailing lists: why do we base proof assistants on dependent type theory?  What are the trade-offs involved?<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">I'm interested both in explanations and arguments given on list, as well as in references to papers that discuss these sorts of choices.<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class=""><o:p class=""> </o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Thanks,<o:p class=""></o:p></div></div><div class=""><div style="margin: 0cm 0cm 0.0001pt 36pt; font-size: 11pt; font-family: Calibri, sans-serif;" class="">Jason<o:p class=""></o:p></div></div></div></div><pre style="caret-color: rgb(0, 0, 0); font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class="">This message and any attachment are intended solely for the addressee
and may contain confidential information. If you have received this
message in error, please contact the sender and delete the email and
attachment. 

Any views or opinions expressed by the author of this email do not
necessarily reflect the views of the University of Nottingham. Email
communications with the University of Nottingham may be monitored 
where permitted by law.



</pre><span style="caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">_______________________________________________</span><br style="caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><span style="caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none; float: none; display: inline !important;" class="">Agda mailing list</span><br style="caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="mailto:Agda@lists.chalmers.se" style="color: rgb(149, 79, 114); text-decoration: underline; font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">Agda@lists.chalmers.se</a><br style="caret-color: rgb(0, 0, 0); font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; word-spacing: 0px; -webkit-text-stroke-width: 0px; text-decoration: none;" class=""><a href="https://lists.chalmers.se/mailman/listinfo/agda" style="color: rgb(149, 79, 114); text-decoration: underline; font-family: AgmenaPro-Regular; font-size: 14px; font-style: normal; font-variant-caps: normal; font-weight: normal; letter-spacing: normal; orphans: auto; text-align: start; text-indent: 0px; text-transform: none; white-space: normal; widows: auto; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px;" class="">https://lists.chalmers.se/mailman/listinfo/agda</a></div></blockquote></div><br class=""></div></div></body></html>