<html><head><meta http-equiv="Content-Type" content="text/html charset=windows-1252"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;">Mario,<div><br><div><div>On 13 Oct 2014, at 22:13, Mario Carneiro <<a href="mailto:di.gama@gmail.com">di.gama@gmail.com</a>> wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div dir="ltr">Hi Rob,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 3:50 PM, Rob Arthan <span dir="ltr"><<a href="mailto:rda@lemma-one.com" target="_blank">rda@lemma-one.com</a>></span> wrote:<br><div></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word"><div></div><div>The reason they aren’t quantified is because OpenTheory follows HOL Light</div><div>in not wiring any dependency on the definitions of the logical connectives and</div><div>quantifiers into the logical kernel. This means that they both have to represent</div><div>the logical content of a the defining property of a new type without using</div><div>universal quantification and implication, which they do using a theorem with</div><div>assumptions and free variables. It would be really nice if there was a simple</div><div>closed formula you could use instead, but no-one has come up with one.</div></div></blockquote><div><br></div><div>Well, there's no need to use the definition of ! : you could just write<br><br></div><div>(\a. (abs (rep a)) = a) = (\a. a = a)<br>(\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r)<br></div><div><br></div><div>and since now the variables are bound, you are free to use whatever dummies you like.<br></div></div></div></div></div></blockquote><div><br></div>But that’s just expanding the definition of the connectives and it’s not very pretty.</div><div>(Strictly speaking, I don’t know whether it is expanding the definition of the</div><div>connectives or not, since you haven’t told me what the type of the second</div><div>variable called r is, and for technical reasons it is boolean in the definition</div><div>of T.)</div><div><br></div><div><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div> <br></div><blockquote class="gmail_quote" style="margin: 0px 0px 0px 0.8ex; border-left-width: 1px; border-left-style: solid; border-left-color: rgb(204, 204, 204); padding-left: 1ex; position: static; z-index: auto;"><div style="word-wrap:break-word"><div>To reiterate, I don’t see why you think the spec required or suggested</div><div>the introduction of dummy free variables. And I don’t see how it will</div><div>help Mario - if his implementation of defineTypeOp produces a theorem</div><div>with dummy variable names, then he will have to implement a derived rule to</div><div>adjust those names to the ones specified in the article (as opposed to “a” and</div><div>“r”, which is what you have to do with version 5 of the article standard).</div></div></blockquote><div><br></div><div>I have no strong feelings or difficulty implementing either standard; rather, as Joe suggested, I find it inelegant to hard-code anything into the spec that isn't necessary. The problem isn't that I am forced to invent a dummy variable, and have to convert it - it's that I have to name it *something*, and since there had been no previous examples of hard-coded names, it was my mistake to interpret the "a" and "r" as dummy names (which is another way to avoid hard-coded names, although as it turns out it's not a viable solution in this case). What I'm trying to do is offload as much responsibility for variable naming into the proof as possible, so that the spec doesn't have to pull names like "a" out of a hat (which may or may not conflict with another variable, or may just not be good variable names for the proof if one has a particular naming convention in mind).<br><br><br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Oct 13, 2014 at 4:52 PM, Rob Arthan <span dir="ltr"><<a href="mailto:rda@lemma-one.com" target="_blank">rda@lemma-one.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div style="word-wrap:break-word">For now, the only system we have to cope with that produces defining<div><div>properties with free variables is HOL Light and it does this for type</div><div>definitions only and it uses the fixed names “a” and “r” for the free variables. </div><div>I appreciate, on reflection, that if it did generate fresh variable names, it</div><div>would be a (not insuperable) challenge to implement an OpenTheory writer for it.</div><div>On the other hand, why would anyone want a definitional principle that</div><div>gave defining properties containing unpredictable free variable names?</div></div></div></blockquote><div><br></div></div></div></div></div></div></div></div></blockquote><div><br></div>I misunderstood what was going on. I thought you were introducing dummy names</div><div>you had an existing implementation of something like defineConst that was forcing</div><div>you to use invented variable names. I didn’t realise you had a choice.</div><div><br></div><div><br><blockquote type="cite"><div dir="ltr"><div><div class="gmail_extra"><div class="gmail_quote"><div><div class="gmail_extra"><div class="gmail_quote"><div>For comparison purposes (and for a glimpse of where I'm coming from), Metamath does this for *every* axiom and theorem. For example, there is a theorem <a href="http://us.metamath.org/mpegif/rabid2.html">http://us.metamath.org/mpegif/rabid2.html</a>, written in Metamath as:<br><br> |- ( A = { x e. A | ph } <-> A. x e. A ph )<br></div><div><br>and which could be translated into HOL as<br><br> |- ((a = (\x. (a x) /\ (P x))) = (!x. (a x) ==> (P x)))<br><br></div><div>When applied as a step in another theorem, the stack machine accepts the label "rabid2" as the command, and treats it as if it were a primitive inference rule which pops "var v", "class B", "wff ps" off the stack (equivalents to "var" and "term" stack entries - here v is an arbitrary variable and B stands for any valid class expression, and ps is any valid wff), and pushes the theorem<br><br> |- ( B = { y e. B | ps } <-> A. y e. B ps )<br><br></div><div>onto the stack. The original (non-substituted) formula, which had previously been exported, never appears on the stack at any point. Thus Metamath is essentially "subst"-ing every single formula that appears on the stack, which on the one hand makes it very powerful, but it does not actually contain a "subst" command, so a formula already on the stack cannot be further substituted unless you get a fresh copy from whatever formulas you derived it from or break off a new lemma.<br><br></div><div>Metamath has nothing hardcoded at all, not even "primitive rules of inference", just this "subst"-like behavior, and axioms which are specified during execution. That's part of the reason why I internally reject having to make arbitrary decisions regarding variable naming which should rightly be done by the proof writer and their own naming sense.<br></div></div></div></div></div></div></div></div></blockquote></div><br></div><div>Unfortunately that is just not how it is in HOL Light.</div><div>The way the equivalent of defineTypeOp is implemented in HOL4</div><div>and ProofPower gives a defining property with no free variables.</div><div>But the HOL4 and ProofPower kernels require that the logical</div><div>connectives and one or two other constants are pre-defined.</div><div>The HOL Light and OpenTheory kernels don’t make this</div><div>requirement, but this causes them to produce defining properties</div><div>for type with free variables. I am rather inclined to agree with</div><div>you that the names of those free variables should be the user’s</div><div>choice. But that is not how HOL Light is at the moment.</div><div><br></div><div>Regards,</div><div><br></div><div>Rob.</div></body></html>