From rote at inf.fu-berlin.de Thu Aug 6 14:30:39 2015 From: rote at inf.fu-berlin.de (=?UTF-8?B?R8O8bnRlciBSb3Rl?=) Date: Thu, 06 Aug 2015 16:30:39 +0200 Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be used as a proof verifier Message-ID: <55C36F8F.6030503@inf.fu-berlin.de> I am trying to write an article reader in python, mainly to get an understanding how the steps of a formal proof in HOL look like. My question concerns the definition of *defineTypeOp* in the article file format http://www.gilith.com/research/opentheory/article.html Since the new constants *abs* and *rep* appear in a term like "(? (?a. abs (rep a)) = ?a. a)", they must have some type: I guess the new type operator op with name n has type parameters ?1 ... ?k in this order, and the types of rep and abs are rep:: n ?1 ... ?k -> b abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator) where b is the type of t Is that true? In the definition of *opType*, is it required that the length n of the list equals the k with which the type-operator "op" has been defined? (Maybe my question is based on a basic misunderstanding: Can opentheory be used as a proof verifier? I.e. If an article file goes through opentheory without errors, does it mean that the listed "theorems" can be derived from the "assumptions" (using the OpenTheory derivation rules)? (I have seen talks about proof verification by transforming opentheory to dedukti (or rather HOL via opentheory to dedukti) and then verifying the proof in dedukti. What would be the point of this if this verification is also fine in opentheory?) -- G"unter Rote (Germany=49)30-838-75150 (office) Freie Universit"at Berlin Institut f"ur Informatik -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5311 bytes Desc: S/MIME Cryptographic Signature URL: From Ramana.Kumar at cl.cam.ac.uk Sat Aug 8 01:02:12 2015 From: Ramana.Kumar at cl.cam.ac.uk (Ramana Kumar) Date: Sat, 8 Aug 2015 11:02:12 +1000 Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be used as a proof verifier In-Reply-To: <55C36F8F.6030503@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> Message-ID: On 7 August 2015 at 00:30, G?nter Rote wrote: > I am trying to write an article reader in python, mainly to > get an understanding how the steps of a formal proof in HOL look like. > Sounds like a good idea. > My question concerns the definition of *defineTypeOp* > in the article file format > http://www.gilith.com/research/opentheory/article.html > > Since the new constants *abs* and *rep* > appear in a term like "(? (?a. abs (rep a)) = ?a. a)", > they must have some type: > > I guess the new type operator op with name n has > type parameters ?1 ... ?k in this order, and > the types of rep and abs are > rep:: n ?1 ... ?k -> b > abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator) > where b is the type of t > Is that true? > That is correct. > In the definition of *opType*, is it required that > the length n of the list equals the k with which > the type-operator "op" has been defined? > Kind of true, but not really. Type operators can be constructed by the virtual machine even if they have not previously been defined in the same article. In that case, the type operator will be one of the "external type operators" (i.e., an input) to the resulting theory. (N.B. if you use *typeOp* to create a type operator with the same name as one created by *defineTypeOp*, they won't alias each other; i.e., if you want to use the type defined by *defineTypeOp* you have to use the TypeOp object that it returns. Some related previous mails on this point: http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html.) However, I think if you are using a type operator whose definition is known and supply the wrong number of arguments, article processing will fail. Joe can probably confirm and clarify this. > (Maybe my question is based on a basic misunderstanding: > Can opentheory be used as a proof verifier? > I.e. If an article file goes through opentheory without > errors, does it mean that the listed "theorems" can be > derived from the "assumptions" (using the OpenTheory derivation rules)? > Yes. The opentheory tool can be used to verify that articles obey the derivation rules of (OpenTheory's variant of) HOL. > (I have seen talks about proof verification by transforming opentheory to > dedukti (or rather HOL via opentheory to dedukti) and then verifying the > proof in dedukti. What would be the point of this if this > verification is also fine in opentheory?) > There are at least two points to make here: 1. Dedukti verifies proofs in a different logical system, lambda pi modulo rewriting, in which HOL (e.g., OpenTheory) can be embedded. The idea is that it could be a place where theories from different logics could be combined. Thus it makes sense to import into Dedukti, even if you trust the opentheory-checked version is correct, to allow the connection with other things in Dedukti. 2. It's always good to have multiple implementations of a proof checker, since proof checkers can contain bugs but the chances of two very different implementations having the same bugs are low. (To be clear, proof checkers don't typically have many bugs, but it's possible.) The opentheory tool wasn't designed primarily as a proof checker (it has other design goals too), so it's not the smallest and simplest piece of code doing that job, hence maybe you would prefer to trust an independent, purpose-built checker. (I don't think Dedukti is that either though.) The CakeML project (of which I'm a developer) takes the idea of reducing the need to trust the proof checker to an extreme: we are working on a proof checker whose machine-code implementation is itself verified to only accept theories that are true in all (standard) models of higher-order logic. (Verified in the sense of having a proof in OpenTheory deriving that fact.) > > -- > G"unter Rote (Germany=49)30-838-75150 (office) > Freie Universit"at Berlin > Institut f"ur Informatik > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sat Aug 8 01:16:09 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 7 Aug 2015 21:16:09 -0400 Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be used as a proof verifier In-Reply-To: References: <55C36F8F.6030503@inf.fu-berlin.de> Message-ID: Hi Gunter and Ramana, >> I guess the new type operator op with name n has >> type parameters ?1 ... ?k in this order, and >> the types of rep and abs are >> rep:: n ?1 ... ?k -> b >> abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator) >> where b is the type of t >> Is that true? > > That is correct. Thanks for the clarification, I have added a note to defineConst and defineTypeOp to spell this out: http://www.gilith.com/research/opentheory/article.html#defineConstCommand http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > However, I think if you are using a type operator whose definition is known > and supply the wrong number of arguments, article processing will fail. Joe > can probably confirm and clarify this. I don't believe this affects soundness, so I regard this as implementation-dependent behaviour. In the opentheory logical kernel you can use a defined type operator with the wrong number of arguments or a defined constant outside of its principal type, but there won't be much you can prove about such types/terms. The logical kernels of other systems might throw an exception if you try to construct such types/terms. > Yes. The opentheory tool can be used to verify that articles obey the > derivation rules of (OpenTheory's variant of) HOL. Agreed, and not just the opentheory tool, but any tool that processes articles (such as your python tool in development). Cheers, Joe From rote at inf.fu-berlin.de Sun Aug 9 09:02:02 2015 From: rote at inf.fu-berlin.de (=?UTF-8?B?R8O8bnRlciBSb3Rl?=) Date: Sun, 09 Aug 2015 11:02:02 +0200 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: References: <55C36F8F.6030503@inf.fu-berlin.de> Message-ID: <55C7170A.6080603@inf.fu-berlin.de> Am 08.08.2015 um 03:16 schrieb Joe Leslie-Hurd: > Thanks for the clarification, I have added a note to defineConst and > defineTypeOp to spell this out: > > http://www.gilith.com/research/opentheory/article.html#defineConstCommand > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand Thanks. But what is the *principal* type of the new constant? (And maybe you want to update defineConstList as well?) Am 15.01.2011 um 03:16 schrieb Joe Leslie-Hurd: http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html >> Also, it's not clear whether a "new constant" with the same name as >> a previously defined constant is allowed. I presume so. > > This is left to the system, which must be careful to disallow > 1. define `c = T` 2. define `c = F` 3. prove `T = F` > > I believe all of the HOL theorem provers maintain a symbol table of > constants, and will not allow redefinitions with the same name. The > logical kernel of the opentheory tool stores the definition with the > constant, so will happily allow redefinitions with the same name > (because the two "c" constants above will be treated as different > constants). This puzzles me. If I now create another "instance" of a constant with name c (and type bool) by a const+constTerm command, to which constant from among definitions 1 or 2 (if any) does it refer to? (More specifically, to which c will it be alpha-equivalent, when this is for example tested in the course of eqMP?) And does the answer change for a constant c that was "created" before definitions 1 and 2? best regards : G?nter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5311 bytes Desc: S/MIME Cryptographic Signature URL: From Ramana.Kumar at cl.cam.ac.uk Sun Aug 9 12:49:41 2015 From: Ramana.Kumar at cl.cam.ac.uk (Ramana Kumar) Date: Sun, 9 Aug 2015 22:49:41 +1000 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: <55C7170A.6080603@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> Message-ID: On 9 August 2015 at 19:02, G?nter Rote wrote: > Am 08.08.2015 um 03:16 schrieb Joe Leslie-Hurd: > > Thanks for the clarification, I have added a note to defineConst and > > defineTypeOp to spell this out: > > > > > http://www.gilith.com/research/opentheory/article.html#defineConstCommand > > > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > > Thanks. But what is the *principal* type of the new constant? > HOL constants are polymorphic. But the type of every instance of a particular constant is a type instance of one particular type. That one type is the principal type of the constant. > (And maybe you want to update defineConstList as well?) > Yes, I think an analogous note would make sense. > > Am 15.01.2011 um 03:16 schrieb Joe Leslie-Hurd: > http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html > >> Also, it's not clear whether a "new constant" with the same name as > >> a previously defined constant is allowed. I presume so. > > > > This is left to the system, which must be careful to disallow > > > 1. define `c = T` > 2. define `c = F` > 3. prove `T = F` > > > > I believe all of the HOL theorem provers maintain a symbol table of > > constants, and will not allow redefinitions with the same name. The > > logical kernel of the opentheory tool stores the definition with the > > constant, so will happily allow redefinitions with the same name > > (because the two "c" constants above will be treated as different > > constants). > > This puzzles me. > If I now create another "instance" of a constant with name c > (and type bool) by a const+constTerm command, to which > constant from among definitions 1 or 2 (if any) does it > refer to? Neither. The only way to get the constants from the definitions in 1 and 2 is as the objects returned by the definition commands. > (More specifically, to which c will it be > alpha-equivalent, when this is for example tested in > the course of eqMP?) > (neither) > And does the answer change for a constant c that was > "created" before definitions 1 and 2? > No. (I'm not 100% confident of these three answers; Joe will know best.) > > best regards : G?nter > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Aug 9 14:13:30 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 9 Aug 2015 10:13:30 -0400 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> Message-ID: >> (And maybe you want to update defineConstList as well?) > > Yes, I think an analogous note would make sense. Done: http://www.gilith.com/research/opentheory/article.html#defineConstListCommand >> If I now create another "instance" of a constant with name c >> (and type bool) by a const+constTerm command, to which >> constant from among definitions 1 or 2 (if any) does it >> refer to? > > Neither. The only way to get the constants from the definitions in 1 and 2 > is as the objects returned by the definition commands. Ramana has this right. And to answer your follow-up question, since the opentheory logical kernel is purely functional it doesn't matter which order definitions happen. Cheers, Joe From rote at inf.fu-berlin.de Sun Aug 9 14:32:31 2015 From: rote at inf.fu-berlin.de (=?windows-1252?Q?G=FCnter_Rote?=) Date: Sun, 09 Aug 2015 16:32:31 +0200 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> Message-ID: <55C7647F.60304@inf.fu-berlin.de> > http://www.gilith.com/research/opentheory/article.html#defineConstListCommand > >>> If I now create another "instance" of a constant with name c >>> (and type bool) by a const+constTerm command, to which >>> constant from among definitions 1 or 2 (if any) does it >>> refer to? >> >> Neither. The only way to get the constants from the definitions in 1 and 2 >> is as the objects returned by the definition commands. > > Ramana has this right. And to answer your follow-up question, since > the opentheory logical kernel is purely functional it doesn't matter > which order definitions happen. > O.K. (But it appears more like a object-oriented feature to me: nothing is equal unless one explicitly defines it to be equal). Two more questions: 1) If I create several constants with name c (and the same type bool) by a sequence of const+constTerm commands, are they equal (alpha-equivalent) to each other? (Like "T" and "T"?) 2) If I define two constants c with the defineConst command with the *same* definition, are they considered equal? In any case, I think the documentation needs some clarification, in particular here: const Higher order logic constants, such as T and =. *Constants are identified by name* It seems rather that the name acts merely as a comment in the above cases. regards : G?nter -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5311 bytes Desc: S/MIME Cryptographic Signature URL: From joe at gilith.com Sun Aug 9 15:03:27 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 9 Aug 2015 11:03:27 -0400 Subject: [opentheory-users] Definition of "term" (plus other issues) In-Reply-To: <55C72710.3020603@inf.fu-berlin.de> References: <55C72710.3020603@inf.fu-berlin.de> Message-ID: [cc'ing the OpenTheory mailing list] Hi Gunter, Thank you very much for suggesting these clarifications. It is always useful to hear what is confusing to people reading the article standard for the first time. I have incorporated all of your suggestions into the standard: http://www.gilith.com/research/opentheory/article.html Please take a look and let me know if that would have helped you. Cheers, Joe On Sun, Aug 9, 2015 at 6:10 AM, G?nter Rote wrote: > Dear Joe. > Here is another thing which I did not learn explicitly from the > specification but the "hard way" > > 1. I think the following definition is misleading, in particular the > examples. > > term > Higher order logic terms, such as 13 and ?x. x. Terms are > ?-equivalent if they are equal up to a consistent renaming of bound > variables, so ?x y. p x y is ?-equivalent to ?y x. p y x but not to ?y > x. p x y. > > terms are not just the expression, but they always come with a type. > the examples might be > 13:bool->bool > or > ?x. x: bool > or perhaps something more instructive > ?x. f x: (a->int) ->(b->int) > > 2. Another clarification that might be worth mentioning: (I think this > issue has come up in the mailing list). > > when you write ? ? ?, you are referring to the binary type operator > with name '->', and not with name "?", (despite utf-8 input) > (I guess in prettyprinted html output they would both be rendered > identically? > > 3. in appTerm and appThm > Constraint: The term f must have a type of the form ? ? ?, and the > term x must have a matching type ?. > > I guess when you write "x must have a *matching* type ?." you just mean > "x must have type ?." I was wondering whether "matching" could have > been meant in some technical sense such as matching after renaming of type > variables or even something more elaborate such as unification. > > (And, the resulting term f x will (obviously) have type ?.) > > 4. maybe you want to say something about the result type in absTerm > > With best regards : G?nter > From joe at gilith.com Sun Aug 9 18:56:35 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 9 Aug 2015 14:56:35 -0400 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: <55C7647F.60304@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> Message-ID: Hi Gunter, > O.K. (But it appears more like a object-oriented feature to me: > nothing is equal unless one explicitly defines it to be equal). I'd highly encourage that view: if you only build objects once and store them in a dictionary if they are used multiple times, then equality will be nice and boring. > Two more questions: > 1) If I create several constants with name c > (and the same type bool) by a sequence of const+constTerm commands, > are they equal (alpha-equivalent) to each other? > (Like "T" and "T"?) Yes: these will be equal. > 2) If I define two constants c with the defineConst command > with the *same* definition, are they considered equal? This is implementation-dependent. Some theorem proving systems will not allow you to define two constants with the same name, some will allow it if the definitions are equal, and some (like opentheory) will be fine with it and will give equal constants if the definitions are equal. > In any case, I think the documentation needs some clarification, > in particular here: > > const > Higher order logic constants, such as T and =. > *Constants are identified by name* > > It seems rather that the name acts merely as a comment in the above cases. I agree that this is unclear, in the light of the above examples. For now I have removed the confusing part you have highlighted. Cheers, Joe From rote at inf.fu-berlin.de Thu Aug 13 14:15:59 2015 From: rote at inf.fu-berlin.de (=?windows-1252?Q?G=FCnter_Rote?=) Date: Thu, 13 Aug 2015 16:15:59 +0200 Subject: [opentheory-users] definition of "new" constants? / processing of packages In-Reply-To: <55C861C3.1090608@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> <55C861C3.1090608@inf.fu-berlin.de> Message-ID: <55CCA69F.7050605@inf.fu-berlin.de> On 10.08.2015 10:33, G?nter Rote wrote: > Thanks. I'll go with this in the implementation. (maybe issue a warning) > Although it is somewhat baroque. > Two constant terms are considered equal if > (a) they were both generated by constTerm commands and > have the same name and type > (b) they were both generated by defineConst commands > with the same name and definition (including type) > and (c) they are the abs or rep constants that were defined in the same defineTypeOp statement. > > I am beginning to wonder how different constants with the same name > will survive the interface between several article files in > a safe and sound way. Dear Joe! I gave it a try, and I found that it is forbidden to use two constants with different definitions and the same name in exported theorems (using thm) and perhaps also assumptions (using axiom): This makes perfect sense for a sound proof checker, but it should be part of the specification. ==================== >opentheory info two-const-conflict.art FATAL ERROR: opentheory failed: different constants named "C" ==================== When opentheory processes a theory, does it read all theory article files on which it depends? Or is there a way that it just needs to read the theorems from other packages that it uses? (In trying to understand how the interface between theories works, I have looked at http://www.gilith.com/research/opentheory/theory.html and the paper "Composable Packages for Higher Order Logic Theories", which is outdated in this respect. (Incidentally, your version of the Schr?der?Bernstein theorem might require the axiom of choice, see https://en.wikipedia.org/wiki/Schr%C3%B6der%E2%80%93Bernstein_theorem Here are some questions: What is the checksum entry? I can somehow guess what the entry show: "Data.Bool" in the .thm file means, but it is not completely clear. In particular, what happens when there are several "show: " lines? Is there a way to eventually look at the theorems that are proved in detail in an unambiguous format with all type information? (other than the html format with mouse-over?) Best regards : -- G"unter Rote (Germany=49)30-838-75150 (office) Freie Universit"at Berlin -75103 (secretary) Institut f"ur Informatik FAX (49)30-838-75192 Takustrase 9, D-14195 Berlin, GERMANY -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5311 bytes Desc: S/MIME Cryptographic Signature URL: From ramana at member.fsf.org Fri Aug 14 06:09:27 2015 From: ramana at member.fsf.org (Ramana Kumar) Date: Fri, 14 Aug 2015 16:09:27 +1000 Subject: [opentheory-users] definition of "new" constants? / processing of packages In-Reply-To: <55CCA69F.7050605@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> <55C861C3.1090608@inf.fu-berlin.de> <55CCA69F.7050605@inf.fu-berlin.de> Message-ID: Dear G?nter, I can answer some but not all of your questions, and do so below. On 14 August 2015 at 00:15, G?nter Rote wrote: > When opentheory processes a theory, does it read all theory article files > on which it depends? > opentheory would need to know the logical content (the theory inputs and outputs) of the dependencies, in order to calculate the theory inputs and outputs of the theory being processed. Whether it figures these out by processing the dependencies or using some caches, I'm not sure. > Or is there a way that it just needs to read the theorems from > other packages that it uses? > I suspect there is a cache, but Joe would know. > I can somehow guess what the entry > show: "Data.Bool" > in the .thm file means, but it is not completely clear. > In particular, what happens when there are several "show: " lines? > Each "show: " line adds another bit of namespace that won't need to be printed. I agree that their exact format and effect is a bit mysterious, though. > Is there a way to eventually look at the theorems that are proved > in detail in an unambiguous format with all type information? (other than > the html > format with mouse-over?) > I would say that the article itself is this "unambiguous format". If you want to see a term in any other format, you can write an article parser that will build the term and then print it however you like. > > Best regards : > -- > G"unter Rote (Germany=49)30-838-75150 (office) > Freie Universit"at Berlin -75103 (secretary) > Institut f"ur Informatik FAX (49)30-838-75192 > Takustrase 9, D-14195 Berlin, GERMANY > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sat Aug 15 17:30:18 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 15 Aug 2015 10:30:18 -0700 Subject: [opentheory-users] definition of "new" constants? / processing of packages In-Reply-To: <55CCA69F.7050605@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> <55C861C3.1090608@inf.fu-berlin.de> <55CCA69F.7050605@inf.fu-berlin.de> Message-ID: Hi Gunter, > I gave it a try, and I found that it is forbidden to use > two constants with different definitions and the same name > in exported theorems (using thm) and perhaps also assumptions (using axiom): > This makes perfect sense for a sound proof checker, > but it should be part of the specification. I agree, although I'm not sure whether it's part of the article spec or the theory spec. If you're reading an article inside a theorem prover it might be ok to have two different constants with the same name (depending on the design of the logical kernel), so I hesitate to forbid it for articles. However, in the context of a theory constants are imported by name, so there cannot be two constants in scope with the same name. So perhaps the theory spec is the place to forbid this: http://www.gilith.com/research/opentheory/theory.html > ==================== >>opentheory info two-const-conflict.art > > FATAL ERROR: opentheory failed: > different constants named "C" > ==================== The opentheory tool reads articles inside an implicit "article block" (see the theory spec), which is why your test article explodes. > When opentheory processes a theory, does it read all theory article files > on which it depends? > Or is there a way that it just needs to read the theorems from > other packages that it uses? It just reads the statement of the theorems generated when the package is installed. See this FAQ: http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files > What is the checksum entry? The checksum is the package checksum. The opentheory tool allows you to specify a package checksum when you install packages, to ensure you are getting the exact package you want. > I can somehow guess what the entry > show: "Data.Bool" > in the .thm file means, but it is not completely clear. > In particular, what happens when there are several "show: " lines? These are namespace abbreviations, as mentioned in the example package file: http://www.gilith.com/research/opentheory/example-1.0.html When printing names the first show: line that matches a prefix of the namespace gets applied, and the name is either rewritten (if the line is show: "X" as "Y") or abbreviated (if the line is show: "X"). > Is there a way to eventually look at the theorems that are proved > in detail in an unambiguous format with all type information? (other than the html > format with mouse-over?) In machine-readable format you can look at the generated theorem files described above. In human-readable format you can see types using: $ opentheory --show-types info --theory natural-def and you can additionally bypass any show: declarations by converting to an article first: $ opentheory info --article natural-def | opentheory --show-types info article:- Cheers, Joe From joe at gilith.com Sat Aug 15 17:35:01 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 15 Aug 2015 10:35:01 -0700 Subject: [opentheory-users] format of opentheory parameters In-Reply-To: <55CDF3F6.1040201@inf.fu-berlin.de> References: <55CDF3F6.1040201@inf.fu-berlin.de> Message-ID: [cc'ing the opentheory mailing list] Hi Gunter, > INPUT is one of the following: > - A package: NAME-VERSION or NAME (for the latest version) > - A theory source file: FILE.thy or theory:FILE > - ... What this meant to say (and I agree it's not crystal clear) is that if the file has an extension .thy it will be treated by default as a theory file, but you can treat any other file as a theory file by prepending theory: to the name of the file. So if you have a theory file two_c.thy you can process it just using opentheory info two_c.thy but if you have a theory file called two_c.txt then you will need to prepend theory: for the opentheory tool to properly interpret it: opentheory info theory:two_c.txt >>opentheory info two_c.thy > triggers > opentheory: unknown type of input: two_c.thy In the light of the above, this error is very strange. What platform are you on? Cheers, Joe From joe at gilith.com Sun Aug 16 03:31:01 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 15 Aug 2015 20:31:01 -0700 Subject: [opentheory-users] format of opentheory parameters In-Reply-To: <55CF7A71.7040802@inf.fu-berlin.de> References: <55CDF3F6.1040201@inf.fu-berlin.de> <55CF7A71.7040802@inf.fu-berlin.de> Message-ID: [cc'ing the opentheory mailing list] Hi Gunter, I've just finished investigating this issue, and discovered that the opentheory tool had some hidden constraints: 1. For a FILE.thy to be recognized as a theory, FILE had to be a valid package name. 2. For a FILE.tgz to be recognized as a tarball, FILE had to be a valid package name-version. These hidden constraints are simply confusing and serve no useful purpose that I can discover, so I have removed them and released a new version of the opentheory tool. Your original invocation opentheory info two_c.thy should now work just fine (even though two_c is not a valid package name). Thank you for the bug report, Joe On Sat, Aug 15, 2015 at 10:44 AM, G?nter Rote wrote: > Am 15.08.2015 um 19:35 schrieb Joe Leslie-Hurd: >> [cc'ing the opentheory mailing list] >> >> Hi Gunter, >> >>> INPUT is one of the following: >>> - A package: NAME-VERSION or NAME (for the latest version) >>> - A theory source file: FILE.thy or theory:FILE >>> - ... >> >> What this meant to say (and I agree it's not crystal clear) is that if >> the file has an extension .thy it will be treated by default as a >> theory file, but you can treat any other file as a theory file by >> prepending theory: to the name of the file. So if you have a theory >> file two_c.thy you can process it just using >> >> opentheory info two_c.thy >> >> but if you have a theory file called two_c.txt then you will need to >> prepend theory: for the opentheory tool to properly interpret it: > > Yes, that is how I understood it. > >> opentheory info theory:two_c.txt >> >>>> opentheory info two_c.thy >>> triggers >>> opentheory: unknown type of input: two_c.thy >> >> In the light of the above, this error is very strange. What platform are you on? > > Gnu/Linux, more specifically Ubuntu 12.04 > I have compiled opentheory with the mlton compiler. > > From joe at gilith.com Mon Aug 17 04:38:14 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 16 Aug 2015 21:38:14 -0700 Subject: [opentheory-users] definition of "new" constants? In-Reply-To: <55CF8910.2050908@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> <55C861C3.1090608@inf.fu-berlin.de> <55CCA69F.7050605@inf.fu-berlin.de> <55CF8910.2050908@inf.fu-berlin.de> Message-ID: [cc'ing the opentheory mailing list] Hi Gunter, > Somewhere it should be specified what the list of > external type operators, external constants etc. > of an article file are. (which would have to > refer to the state of the virtual machine) I have introduced the concept of external and defined symbols in the article spec: http://www.gilith.com/research/opentheory/article.html See the explanations of constants and type operators, and also the commands typeOp, const and axiom. I have also added some verbiage at the bottom of the Virtual Machine section describing the constraint that there should not be different symbols with the same name in exported theorems. Thank you again for your comments: every new person who reads the standard and gives feedback improves it for everyone. > By the way, I made a systematic catalog of the > article file commands: > http://page.mi.fu-berlin.de/rote/Software/OpenTheory/opentheory-commands.html This is an excellent document, thank you for creating it. If it is in a permanent location would you mind me linking to it from the OpenTheory project page? > I noted that opentheory seems to have a lot of "built-in" > prettyprinting, like 0 for "Number.Natural.zero". > Or is there a mechanism to define such transformations? There is a certain amount of built-in pretty-printing intended to support the standard theory library, but there is no mechanism to extend it further. Cheers, Joe From joe at gilith.com Fri Aug 21 05:14:16 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 20 Aug 2015 22:14:16 -0700 Subject: [opentheory-users] definition of "new" constants? / defineTypeOp rule In-Reply-To: <55D4A7DC.3060701@inf.fu-berlin.de> References: <55C36F8F.6030503@inf.fu-berlin.de> <55C7170A.6080603@inf.fu-berlin.de> <55C7647F.60304@inf.fu-berlin.de> <55C861C3.1090608@inf.fu-berlin.de> <55CCA69F.7050605@inf.fu-berlin.de> <55CF8910.2050908@inf.fu-berlin.de> <55D4A7DC.3060701@inf.fu-berlin.de> Message-ID: [cc'ing opentheory mailing list] Hi Gunter, > (It is fine it you want to Cc the mailing list in your replies; I just don't want to > create too much traffic. The purpose of the OpenTheory mailing list is to answer people's questions and discuss OpenTheory topics, so please don't worry about creating traffic on the list. Also, I prefer to use the mailing list for OpenTheory emails as a public record of the discussions and so other people also have the chance to answer questions. >> I have also added some verbiage at the bottom of the Virtual Machine >> section describing the constraint that there should not be different >> symbols with the same name in exported theorems. > > 1. "must not reference two different constants that have the same name." > > This is stricter than what the opentheory tool currently allows? > (I prefer it that way.) It is not intended to be stricter. The set of constants contained in the exported theorems must have the property that different constants have different names, which I believe is what the opentheory tool requires. Have you encountered a situation that violates this but is permitted by the opentheory tool? > "The same constraint also holds for the set of assumptions ?". > For clarity, I would put it right at the beginning > > "Constraint: The set of theorems ? and assumptions ? must not ..." > > (otherwise it looks as if one constant in ? and a different constant in ? were o.k. Actually there's nothing wrong with this scenario: it's just some sloppy programming in the opentheory tool that generated an error in this case. I've just released a new version of the opentheory tool that permits this scenario (with a warning) and added a new test case that demonstrates it: $ opentheory info test/articles/example12.art WARNING: 2 different constants named c 1 external type operator: bool 1 external constant: c 1 assumption: |- c 1 defined constant: c 1 theorem: |- c > 3. another question: I don't completely see through the definetypeop > rule. > > a) Is the role of Thm(? ? t) only to specify the type of t? The main purpose is to prove that the predicate \phi is non-empty, which is a required condition of every higher order logic type. > b) When I look at the *list* type operator > in list-def-1.63.art > it is defined with the type of t being bool. These files are just the theorem caches for a package, they do not define symbols properly. They are really only intended for internal use to optimize theory dependency computations: http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files I recommend simply ignoring these files: they are a great source of confusion. > c) Is there an example where rep and abs and the theorems are not > thrown away? My standard pattern is to define a type, use the abs/rep constants and bijection theorems to define some other constants and prove some characteristic theorems about the new type, and then export these characteristic theorems from the theory. This effectively hides the primitive abs/rep constants returned from defineTypeOp inside the theory abstraction. > d) Where can I find some background information on the > defineTypeOp rule of the OpenTheory logical kernel? > (PS. I found some explanation on p. 81 in > https://who.rocq.inria.fr/Ali.Assaf/research/thesis.pdf Take a look at the HOL4 "Logic" manual: http://hol-theorem-prover.org/documentation.html Section 2.5.4 describes type definition. Cheers, Joe From ramana at member.fsf.org Mon Aug 31 05:24:29 2015 From: ramana at member.fsf.org (Ramana Kumar) Date: Mon, 31 Aug 2015 15:24:29 +1000 Subject: [opentheory-users] importer for Isabelle In-Reply-To: References: Message-ID: Hi Brian, Could I trouble you to look for a copy of your OpenTheory-related code for Isabelle? I'd like to see if I can get it working. Oh, actually I just found this link: http://www4.in.tum.de/~huffman/cgi-bin/repos.cgi/OpenTheory So, I can get started with that, but if you have any comments or ideas they could probably still be helpful :) Cheers, Ramana On 6 July 2015 at 20:54, Ramana Kumar wrote: > Yes, if it works (or is close to working) I would like to get it > incorporated into the Isabelle codebase. I'm not yet sure how to contribute > things to Isabelle, but I imagine I'll find out within the next few months. > > On 23 May 2015 at 15:52, Brian Huffman wrote: > >> I've hardly looked at it since I wrote it. It was never incorporated >> into the Isabelle codebase. I suppose it would probably work with the >> latest Isabelle, because it uses only the low-level proof kernel api, >> which doesn't change much any more. >> >> I'll have to look around to see where I have a copy of the source >> code; that was a couple of computers ago. Did you want to try to do >> something with it? >> >> - Brian >> >> >> On Sat, May 23, 2015 at 5:13 AM, Ramana Kumar >> wrote: >> > Hi Brian, >> > >> > What's the status of your OpenTheory importer? Does it work with the >> > latest Isabelle? Was it incorporated into the main code base? >> > >> > Cheers, >> > Ramana >> > >> > On 15 April 2011 at 17:34, Brian Huffman wrote: >> >> On Thu, Apr 14, 2011 at 7:03 PM, Joe Hurd wrote: >> >>> Hi Brian, >> >>> >> >>> That is really great work! Am I right in thinking you can import the >> >>> parser-1.5 article binding all the input symbols and axioms to >> >>> existing ones in Isabelle? I would have guessed that Isabelle type >> >>> classes would have managed to get in the way at some point, but >> >>> perhaps this would only be for converting Isabelle proofs to >> >>> OpenTheory format? >> >> >> >> Yes, each of the input constants of the article is mapped to a >> >> pre-existing Isabelle constant. Some of these existing Isabelle >> >> constants happen to be overloaded, but that doesn't cause any >> >> problems. This mapping of constant names does not even need to be >> >> one-to-one; for example, I imagine that "Number.Natural.+" and >> >> "Number.Integer.+" would map to the same overloaded "plus" constant in >> >> Isabelle. >> >> >> >> Of course, exporting proofs from Isabelle is a completely different >> story. >> >> >> >>> You mentioned that you prove a lot of theorems that the OpenTheory >> >>> article relies on, but it seems you could reduce this by processing a >> >>> set of OpenTheory packages that don't make any definitions. When I was >> >>> designing the standard theory library I tried to isolate packages that >> >>> made definitions and have them export just a minimal theorem interface >> >>> - most of the theorems are proved in packages that make no definitions >> >>> and so can be safely run to populate the [opentheory] set of theorems. >> >> >> >> Your idea of keeping definitions in separate, minimal modules is a >> >> good design. I'm sure I could have greatly reduced the number of >> >> [opentheory] lemmas that I needed by finding the right additional >> >> article files to import; I was just too lazy to figure out how the >> >> packages were organized. >> >> >> >>>> The importer should also extend these tables whenever it defines a >> new >> >>>> constant or type, but I haven't implemented this yet. Another nice >> >>>> feature would be a way for users to influence how the importer >> chooses >> >>>> names for newly-defined constants and types. Right now it takes the >> >>>> names directly from the strings in the article file, which isn't so >> >>>> nice for names like "HOLLight._dest_rec" (Isabelle's parser can't >> >>>> handle names that start with underscores). >> >>> >> >>> You should find that constants and type operators with names like this >> >>> are never exported from a theory (i.e., never appear in exported >> >>> theorems), so it's perfectly safe to normalize their names to >> >>> something more acceptable to Isabelle. They are `local definitions' >> >>> that are used only in proofs. >> >> >> >> Actually, it seems like it would be safe to rename *any* constant >> >> (whether exported or not) to any name that I want in Isabelle, as long >> >> as the importer keeps track of the name mapping so that later imports >> >> can use the same names. >> >> >> >> I suppose I should write an "import_name" function that converts from >> >> OpenTheory names to Isabelle-friendly ones. It would be nice to >> >> parameterize this by a list of user-specified exceptions to the >> >> mapping, so you could say something like, "import this article, but >> >> when you define constant 'foo', call it 'bar' instead." >> >> >> >>>> Once I clean up the code, I'm not sure what I should do with it... I >> >>>> suppose I could add it to the Isabelle repo, but I'm not sure if I >> >>>> want to advertise to Munich crowd that I've been doing all this work >> >>>> that is unrelated to finishing my thesis :) >> >>> >> >>> I would very much like to see it live on in some fashion - my hope is >> >>> that more and more theories will be converted to OpenTheory packages, >> >>> and your code could be used to import them into Isabelle in a >> >>> principled way. >> >> >> >> I suppose I'll add it to the Isabelle distribution at some point, >> >> maybe after I finish writing my thesis. In the meantime, I guess I can >> >> post the code to the list, so it will be archived and people can try >> >> it out. >> >> >> >> - Brian >> >> >> >> _______________________________________________ >> >> opentheory-users mailing list >> >> opentheory-users at gilith.com >> >> http://www.gilith.com/mailman/listinfo/opentheory-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: