From rda at lemma-one.com Fri Feb 14 13:13:32 2014 From: rda at lemma-one.com (Rob Arthan) Date: Fri, 14 Feb 2014 13:13:32 +0000 Subject: [opentheory-users] Description of the project goals Message-ID: <7B8FFE02-C4CA-4761-BFB4-CB542F28E1D9@lemma-one.com> The OpenTheory home page says that the goal of the project is to allow proofs to be shared between different theorem prover implementations. May I request that this be clarified by changing "proofs" to "specifications and proofs", if no-one objects and if Joe has time to do it. My reason for the request is that my work on OpenTheory is in part supported by people who understand the concept of specification better than the concept of proof, and it will not be obvious to them that transferring proofs includes transferring specifications. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Tue Feb 18 16:46:36 2014 From: rda at lemma-one.com (Rob Arthan) Date: Tue, 18 Feb 2014 16:46:36 +0000 Subject: [opentheory-users] Type variable names Message-ID: <3ECF799F-BDD8-4B6D-A1AF-62F7064ABB78@lemma-one.com> I have a problem with edge cases in the mappings of type variable names. What currently happens is that I export them as they stand and import them by prefixing them with a prime if they don't already start with one. Ramana does something more complicated by also converting a primed single letter to upper case on output and to lower case on input. The upshot of this is 'a in ProofPower imports as 'a in HOL4 which then imports back into ProofPower as 'A which imports back into HOL4 as 'a and now we are in a loop. This is harmless but a bit silly. So should I be adjusting the case like Ramana does? And if so why? Since a HOL4 or ProofPower theory with non-standard type variable names looks a mess and since the Gilith OpenTheory Repo seems to have standardised on what HOL4 and ProofPower consider non-standard, these mappings are necessary. Unfortunately, they also need to be one-to-one and this is not the case for what I do when importing or what Ramana does when importing or exporting without some assumptions. What assumptions can we reasonably make? Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Tue Feb 18 17:12:47 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 18 Feb 2014 17:12:47 +0000 Subject: [opentheory-users] Scalable LCF-style proof translation In-Reply-To: References: <51F98657.4040208@in.tum.de> <52002C01.5050708@in.tum.de> Message-ID: Hi Joe, Cezary, Alex, I am planning, in the next few months, to export an extremely large proof from HOL4 into a format where I can check it with a standalone checker. (This proof takes hours to construct in HOL4.) OpenTheory seems the obvious choice as a proof storage medium, but the current format and implementations struggle with even moderate-sized proofs. I'd be very interested to hear about progress towards using the ideas from Cezary and Alex's paper to improving the scalability of OpenTheory technology. Have you made any progress on this front? Would you be interested in working on it with me? I hope we will be able to coordinate on this, since I think it's important work and each of us has something crucial to offer towards it. As a first item, I would think that the OpenTheory article format needs to be updated, as we were discussing earlier. Joe, Alex, did you come to any conclusions about whether changes are necessary and what they would look like? Cheers, Ramana On Tue, Aug 6, 2013 at 1:02 AM, Ramana Kumar wrote: > On Mon, Aug 5, 2013 at 11:49 PM, Alexander Krauss wrote: >> >> >>> The opentheory tool post-processes articles extracted from theorem >>> provers, for compression and neatness purposes. To that end it does >>> both of the things you call out. >> >> >> Which command do I have to run to get this? > > > Install opentheory as per > http://www.gilith.com/software/opentheory/install.html. > Then run it like: > opentheory info --article --output processed.art input.art From joe at gilith.com Tue Feb 18 17:46:35 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Feb 2014 09:46:35 -0800 Subject: [opentheory-users] Scalable LCF-style proof translation In-Reply-To: References: <51F98657.4040208@in.tum.de> <52002C01.5050708@in.tum.de> Message-ID: Hi Ramana, I'm still not convinced that the proof format in Cezary & Alex's paper is more concise than OpenTheory, here is where the discussion ended last time: On Wed, Jul 31, 2013 at 2:49 PM, Alexander Krauss wrote: > On 07/26/2013 11:29 PM, Joe Leslie-Hurd wrote: > >> Given these minor differences, I'm intrigued by the statement in the >> conclusion: >> >> "In our development we de?ned a new format for proof exchange traces, >> despite >> the existence of other exchange formats. We have tried writing the >> proof trace in the >> OpenTheory format, and it was roughly 10 times bigger." >> >> Cezary, Alex: Would it be possible to share this proof trace in the >> two formats, so I can see what difference is responsible for the >> blow-up? > > > I must pass this question on to Cezary, who made this specific experiment. > I'm not even sure whether this is before or after compression... But just > looking at the list of OpenTheory commands, it seems to me that building up > substitutions as nested lists on the stack is rather complicated. So the 10x size increase may simply have been an artifact of comparing against an uncompressed OpenTheory proof file. If Cezary could dig up the proof files that were used for this comparison, I'd be very happy to take a look and see whether there's something deeper that is going on. Unfortunately I think that proof formats (like both of these) that explicitly record every low-level inference are doomed to be bogged down by massive proofs. I've thought about some ways to scale better, such as adding a new "rewrite" OpenTheory command that behaves like REWRITE_CONV, but such rules are hard to specify precisely to guarantee identical behaviour on different platforms. I'd be interested in hearing your ideas about how to scale better in proof formats while preserving portability. Cheers, Joe On Tue, Feb 18, 2014 at 9:12 AM, Ramana Kumar wrote: > Hi Joe, Cezary, Alex, > > I am planning, in the next few months, to export an extremely large > proof from HOL4 into a format where I can check it with a standalone > checker. (This proof takes hours to construct in HOL4.) OpenTheory > seems the obvious choice as a proof storage medium, but the current > format and implementations struggle with even moderate-sized proofs. > I'd be very interested to hear about progress towards using the ideas > from Cezary and Alex's paper to improving the scalability of > OpenTheory technology. Have you made any progress on this front? Would > you be interested in working on it with me? > > I hope we will be able to coordinate on this, since I think it's > important work and each of us has something crucial to offer towards > it. > > As a first item, I would think that the OpenTheory article format > needs to be updated, as we were discussing earlier. Joe, Alex, did you > come to any conclusions about whether changes are necessary and what > they would look like? > > Cheers, > Ramana > > On Tue, Aug 6, 2013 at 1:02 AM, Ramana Kumar > wrote: > > On Mon, Aug 5, 2013 at 11:49 PM, Alexander Krauss > wrote: > >> > >> > >>> The opentheory tool post-processes articles extracted from theorem > >>> provers, for compression and neatness purposes. To that end it does > >>> both of the things you call out. > >> > >> > >> Which command do I have to run to get this? > > > > > > Install opentheory as per > > http://www.gilith.com/software/opentheory/install.html. > > Then run it like: > > opentheory info --article --output processed.art input.art > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Tue Feb 18 17:54:05 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Feb 2014 09:54:05 -0800 Subject: [opentheory-users] Description of the project goals In-Reply-To: <7B8FFE02-C4CA-4761-BFB4-CB542F28E1D9@lemma-one.com> References: <7B8FFE02-C4CA-4761-BFB4-CB542F28E1D9@lemma-one.com> Message-ID: Hi Rob, I like the change, and indeed see the details of the specifications (statements of theorems and definitions) as more significant than the proofs (where it is only important that a shortish one exists). I've made the change on the main project page: http://www.gilith.com/research/opentheory/ Cheers, Joe On Fri, Feb 14, 2014 at 5:13 AM, Rob Arthan wrote: > The OpenTheory home page says that the goal of the project is to allow > proofs to be shared between different theorem prover implementations. > May I request that this be clarified by changing "proofs" to > "specifications > and proofs", if no-one objects and if Joe has time to do it. > > My reason for the request is that my work on OpenTheory is > in part supported by people who understand the concept of > specification better than the concept of proof, and it will not > be obvious to them that transferring proofs includes transferring > specifications. > > Regards, > > Rob. > > _______________________________________________ > 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 Tue Feb 18 18:22:22 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Feb 2014 10:22:22 -0800 Subject: [opentheory-users] Type variable names In-Reply-To: <3ECF799F-BDD8-4B6D-A1AF-62F7064ABB78@lemma-one.com> References: <3ECF799F-BDD8-4B6D-A1AF-62F7064ABB78@lemma-one.com> Message-ID: Hi Rob, Following our recent discussion on this list http://www.gilith.com/pipermail/opentheory-users/2013-December/000328.html I added the following note to the "varType" command in the article format http://www.gilith.com/research/opentheory/article.html#varTypeCommand Note: The OpenTheory standard theory library adopts the HOL Light convention of naming type variables with capital letters, and theorem provers are expected to map them to local conventions as part of processing articles. For example, in HOL4 it would be natural to map an OpenTheory type variable with name "A" to a local type variable with name "'a". I worked very hard to make the article format agnostic of the choice of symbol names (constants & type operators can be renamed, most commands are blind to alpha-equivalent terms), but unfortunately the names chosen by theorem provers for type variables persist inside OpenTheory proofs. When technical solutions fail, political solutions must take up the slack. In this case, the policy is for type variables in OpenTheory format to be named according to HOL Light conventions (single capital letter, start naming from A, I've no idea what happens if a term requires more than 26), and for other theorem provers to rename on import and export between OpenTheory standard names and native names (just like what already happens with constant and type operator names). So applying the policy to your loopy scenario, I'm afraid it is the ProofPower importer and exporter that is in violation, and I suggest you implement Ramana's HOL4 procedure for importing and exporting type variable names. Then HOL4 and ProofPower should be able to play nicely with each other, and as a bonus with HOL Light too. Cheers, Joe On Tue, Feb 18, 2014 at 8:46 AM, Rob Arthan wrote: > I have a problem with edge cases in the mappings of type variable > names. What currently happens is that I export them as they stand > and import them by prefixing them with a prime if they don't already > start with one. Ramana does something more complicated by also > converting a primed single letter to upper case on output and to > lower case on input. The upshot of this is 'a in ProofPower imports as 'a > in HOL4 which then imports back into ProofPower as 'A which imports > back into HOL4 as 'a and now we are in a loop. This is harmless > but a bit silly. So should I be adjusting the case like Ramana does? > And if so why? > > Since a HOL4 or ProofPower theory with non-standard type variable > names looks a mess and since the Gilith OpenTheory Repo seems > to have standardised on what HOL4 and ProofPower consider > non-standard, these mappings are necessary. Unfortunately, > they also need to be one-to-one and this is not the case for > what I do when importing or what Ramana does when importing or > exporting without some assumptions. What assumptions can we > reasonably make? > > Regards, > > Rob. > > _______________________________________________ > 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 rda at lemma-one.com Wed Feb 19 11:25:55 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 19 Feb 2014 11:25:55 +0000 Subject: [opentheory-users] Type variable names In-Reply-To: References: <3ECF799F-BDD8-4B6D-A1AF-62F7064ABB78@lemma-one.com> Message-ID: <7ACC39A2-E21C-4B6E-A98E-743CCE0B86BC@lemma-one.com> Joe, On 18 Feb 2014, at 18:22, Joe Leslie-Hurd wrote: > Hi Rob, > > Following our recent discussion on this list > > http://www.gilith.com/pipermail/opentheory-users/2013-December/000328.html > > I added the following note to the "varType" command in the article format > > http://www.gilith.com/research/opentheory/article.html#varTypeCommand > > Note: The OpenTheory standard theory library adopts the HOL Light convention of naming type variables with capital letters, and theorem provers are expected to map them to local conventions as part of processing articles. For example, in HOL4 it would be natural to map an OpenTheory type variable with name "A" to a local type variable with name "'a". > > I worked very hard to make the article format agnostic of the choice of symbol names (constants & type operators can be renamed, most commands are blind to alpha-equivalent terms), but unfortunately the names chosen by theorem provers for type variables persist inside OpenTheory proofs. > > When technical solutions fail, political solutions must take up the slack. In this case, the policy is for type variables in OpenTheory format to be named according to HOL Light conventions (single capital letter, start naming from A, I've no idea what happens if a term requires more than 26), I think you will find that this is John Harrison's convention rather than HOL Light's - those As and Bs come from explicit type casts in the HOL Light source. So you'd have to ask John what to do if he wanted more than 26 type variables :-). For the record the ProofPower parser carries on with "'27", "'28" and the HOL4 parser uses "'a0", "'a1". When the HOL Light parser invents type variables they come out as ?N where N is a number that is never the same twice. I have no idea why John implemented it like this - it has the bizarre effect that `x` == `x` returns false in HOL Light. > and for other theorem provers to rename on import and export between OpenTheory standard names and native names (just like what already happens with constant and type operator names). > > So applying the policy to your loopy scenario, I'm afraid it is the ProofPower importer and exporter that is in violation, and I suggest you implement Ramana's HOL4 procedure for importing and exporting type variable names. Then HOL4 and ProofPower should be able to play nicely with each other, and as a bonus with HOL Light too. Well. I will see what it takes to amend Ramana's mapping so that it is guaranteed to be one-to-one. Regards, Rob. > > Cheers, > > Joe > > > > On Tue, Feb 18, 2014 at 8:46 AM, Rob Arthan wrote: > I have a problem with edge cases in the mappings of type variable > names. What currently happens is that I export them as they stand > and import them by prefixing them with a prime if they don't already > start with one. Ramana does something more complicated by also > converting a primed single letter to upper case on output and to > lower case on input. The upshot of this is 'a in ProofPower imports as 'a > in HOL4 which then imports back into ProofPower as 'A which imports > back into HOL4 as 'a and now we are in a loop. This is harmless > but a bit silly. So should I be adjusting the case like Ramana does? > And if so why? > > Since a HOL4 or ProofPower theory with non-standard type variable > names looks a mess and since the Gilith OpenTheory Repo seems > to have standardised on what HOL4 and ProofPower consider > non-standard, these mappings are necessary. Unfortunately, > they also need to be one-to-one and this is not the case for > what I do when importing or what Ramana does when importing or > exporting without some assumptions. What assumptions can we > reasonably make? > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > > _______________________________________________ > 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 ramana at member.fsf.org Tue Feb 25 21:38:45 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 25 Feb 2014 21:38:45 +0000 Subject: [opentheory-users] new_specification Message-ID: Hello OpenTheory! There has been some activity recently considering Rob Arthan's proposal for HOL Constant Definition Done Right [1]. For those unfamiliar, that proposal includes a rule for introducing new constants by conservative extension with a (potentially loose) specification, and it subsumes the functionality of the new_definition and new_specification rules currently implemented in the various HOL provers. The rule has a host of benefits detailed in the paper. My aim here is to encourage OpenTheory and HOL Light to adopt it as well - or at least to invite discussion on that possibility. As I understand it, work is being done to implement this new rule in HOL4 and ProofPower, as a replacement for the primitive rule for defining a new constant by an equation. Of course, as it stands, this breaks compatibility with OpenTheory, since the new rule cannot be reduced to the definitional mechanisms provided in OpenTheory. It would be wonderful to maintain the possibility of proof export, hence my invitation to consider the new rule for OpenTheory. Cheers, Ramana [1] http://www.lemma-one.com/papers/hcddr.pdf From joe at gilith.com Tue Feb 25 22:14:48 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 25 Feb 2014 14:14:48 -0800 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Hi Ramana, I'd never read that note by Rob, and it's very clear and persuasive. Although I have a natural resistance to changing the article file format in any way, the proposed primitive constant definition mechanism does seem to offer an improvement in expressivity at a modest cost of being more complicated to explain. I would consider changing the OpenTheory logical kernel to support it, particularly if HOL4 or ProofPower incorporated it as the primitive constant definition mechanism, but I'd be interested to hear what John has to say about it. Cheers, Joe On Tue, Feb 25, 2014 at 1:38 PM, Ramana Kumar wrote: > Hello OpenTheory! > > There has been some activity recently considering Rob Arthan's > proposal for HOL Constant Definition Done Right [1]. For those > unfamiliar, that proposal includes a rule for introducing new > constants by conservative extension with a (potentially loose) > specification, and it subsumes the functionality of the new_definition > and new_specification rules currently implemented in the various HOL > provers. > > The rule has a host of benefits detailed in the paper. My aim here is > to encourage OpenTheory and HOL Light to adopt it as well - or at > least to invite discussion on that possibility. > > As I understand it, work is being done to implement this new rule in > HOL4 and ProofPower, as a replacement for the primitive rule for > defining a new constant by an equation. Of course, as it stands, this > breaks compatibility with OpenTheory, since the new rule cannot be > reduced to the definitional mechanisms provided in OpenTheory. > > It would be wonderful to maintain the possibility of proof export, > hence my invitation to consider the new rule for OpenTheory. > > Cheers, > Ramana > > [1] http://www.lemma-one.com/papers/hcddr.pdf > > _______________________________________________ > 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: