From joe at gilith.com Tue May 3 03:51:34 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 2 May 2016 20:51:34 -0700 Subject: [opentheory-users] interpretation in separate file In-Reply-To: References: Message-ID: Hi Ramana, Following your suggestion I've written documentation for the interpretation files: http://www.gilith.com/research/opentheory/interpretation.html I've also converted all of my theories on the Gilith repo to use interpretation files rather than interpret: lines, because it's easier to read and keep in sync with my HOL Light source theories. Cheers, Joe On Mon, Apr 25, 2016 at 11:54 PM, Joe Leslie-Hurd wrote: > Yes, the documentation could definitely be improved by describing > interpretation files. Your reverse engineering is quite correct, plus > comments are also allowed. For an example take a look at the > interpretation file used by the latest version of the byte-def theory: > > http://opentheory.gilith.com/opentheory/packages/byte-def-1.98/word.int > > Cheers, > > Joe > > > > On Mon, Apr 25, 2016 at 11:30 PM, Ramana Kumar wrote: >> Hi Joe, >> >> Thanks for implementing this! >> >> I think the documentation isn't very clear about what interpretation files >> should contain. However, I think I figured it out to some extent: They >> should have lines like the "interpret:" lines except without the leading >> "interpret:", and blank lines are allowed. >> >> I'm trying it out more now, and will let you know if I run into anything. >> >> Cheers, >> Ramana >> >> On 24 April 2016 at 16:58, Joe Leslie-Hurd wrote: >>> >>> Hi Ramana, >>> >>> The latest version of the opentheory tool (release 20160423) now >>> includes support for >>> >>> interpretation: "file.int" >>> >>> lines in theory files, as documented here: >>> >>> http://www.gilith.com/research/opentheory/theory.html >>> >>> It's lightly tested, so please let me know if you discover anything >>> odd with the new feature. >>> >>> Cheers, >>> >>> Joe >>> >>> On Wed, Apr 20, 2016 at 9:37 PM, Ramana Kumar >>> wrote: >>> > Cool. Thanks! >>> > >>> > On 21 April 2016 at 02:40, Joe Leslie-Hurd wrote: >>> >> >>> >> By the way, I am working on adding this feature, but for various >>> >> technical reasons of how the code is structured it's turning out to be >>> >> non-trivial. I'll let you know when the feature is added. >>> >> >>> >> Cheers, >>> >> >>> >> Joe >>> >> >>> >> On Sun, Apr 3, 2016 at 10:16 PM, Joe Leslie-Hurd >>> >> wrote: >>> >> > Sure thing, I'll work on adding this feature. >>> >> > >>> >> > Cheers, >>> >> > >>> >> > Joe >>> >> > >>> >> > On Fri, Apr 1, 2016 at 3:41 PM, Ramana Kumar >>> >> > wrote: >>> >> >> Hi Joe, >>> >> >> >>> >> >> I would like to reopen this request. It seems like I'm going to be >>> >> >> copying >>> >> >> interpretations around a lot again. >>> >> >> >>> >> >> Cheers, >>> >> >> Ramana >>> >> >> >>> >> >> On 4 March 2016 at 12:14, Ramana Kumar >>> >> >> wrote: >>> >> >>> >>> >> >>> Hi Joe, >>> >> >>> >>> >> >>> It turns out this is not so urgent for me since Michael and I came >>> >> >>> up >>> >> >>> with >>> >> >>> another method: >>> >> >>> Put all the article-combination stuff into one file >>> >> >>> uninterpreted.thy >>> >> >>> (main block is a union), then turn that into uninterpreted.art, and >>> >> >>> finally >>> >> >>> do the interpretation all at once (so it only appears in one file) >>> >> >>> in >>> >> >>> interpreted.thy, whose main block is an article block for >>> >> >>> "uninterpreted.art". >>> >> >>> >>> >> >>> However, interpretations from files would probably still be good >>> >> >>> for >>> >> >>> other >>> >> >>> scenarios. I would tweak your suggested syntax to use >>> >> >>> "interpretation" >>> >> >>> rather than "interpret-file", to match "article" (which also takes >>> >> >>> a >>> >> >>> filename). >>> >> >>> >>> >> >>> Cheers, >>> >> >>> Ramana >>> >> >>> >>> >> >>> On 5 March 2016 at 05:51, Joe Leslie-Hurd wrote: >>> >> >>>> >>> >> >>>> Hi Ramana, >>> >> >>>> >>> >> >>>> I agree with you that it would be good for theory files to support >>> >> >>>> pulling in interpretations from files. How about the following >>> >> >>>> syntax: >>> >> >>>> >>> >> >>>> interpret-file: "file.int" >>> >> >>>> >>> >> >>>> inside a theory block? It probably makes sense to allow multiple >>> >> >>>> of >>> >> >>>> these, just like multiple >>> >> >>>> >>> >> >>>> interpret: type/const "X" as "Y" >>> >> >>>> >>> >> >>>> lines are allowed, but raise an error if the same symbol is >>> >> >>>> interpreted in multiple ways. >>> >> >>>> >>> >> >>>> Cheers, >>> >> >>>> >>> >> >>>> Joe >>> >> >>>> >>> >> >>>> On Thu, Mar 3, 2016 at 4:21 PM, Ramana Kumar >>> >> >>>> >>> >> >>>> wrote: >>> >> >>>> > Is it possible to include an interpretation in a theory file, >>> >> >>>> > rather >>> >> >>>> > than >>> >> >>>> > having to write it out inline? Since I sometimes want to include >>> >> >>>> > a >>> >> >>>> > rather >>> >> >>>> > large interpretation within multiple blocks within the same >>> >> >>>> > theory >>> >> >>>> > file, I >>> >> >>>> > end up having to write a template file and then generate the >>> >> >>>> > real >>> >> >>>> > .thy >>> >> >>>> > file >>> >> >>>> > from that, to avoid lots of copy-pasting. Is mine the >>> >> >>>> > recommended >>> >> >>>> > approach, >>> >> >>>> > or is there a better way? >>> >> >>>> > >>> >> >>>> > _______________________________________________ >>> >> >>>> > 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 >>> >> >>> >>> >> >>> >>> >> >> >>> >> >> >>> >> >> _______________________________________________ >>> >> >> 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 >>> > >>> > >>> > >>> > _______________________________________________ >>> > 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 >> >> >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> From ramana at member.fsf.org Tue May 3 04:31:04 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 3 May 2016 14:31:04 +1000 Subject: [opentheory-users] interpretation in separate file In-Reply-To: References: Message-ID: Cool :) That looks good. On 3 May 2016 at 13:51, Joe Leslie-Hurd wrote: > Hi Ramana, > > Following your suggestion I've written documentation for the > interpretation files: > > http://www.gilith.com/research/opentheory/interpretation.html > > I've also converted all of my theories on the Gilith repo to use > interpretation files rather than interpret: lines, because it's easier > to read and keep in sync with my HOL Light source theories. > > Cheers, > > Joe > > On Mon, Apr 25, 2016 at 11:54 PM, Joe Leslie-Hurd wrote: > > Yes, the documentation could definitely be improved by describing > > interpretation files. Your reverse engineering is quite correct, plus > > comments are also allowed. For an example take a look at the > > interpretation file used by the latest version of the byte-def theory: > > > > http://opentheory.gilith.com/opentheory/packages/byte-def-1.98/word.int > > > > Cheers, > > > > Joe > > > > > > > > On Mon, Apr 25, 2016 at 11:30 PM, Ramana Kumar > wrote: > >> Hi Joe, > >> > >> Thanks for implementing this! > >> > >> I think the documentation isn't very clear about what interpretation > files > >> should contain. However, I think I figured it out to some extent: They > >> should have lines like the "interpret:" lines except without the leading > >> "interpret:", and blank lines are allowed. > >> > >> I'm trying it out more now, and will let you know if I run into > anything. > >> > >> Cheers, > >> Ramana > >> > >> On 24 April 2016 at 16:58, Joe Leslie-Hurd wrote: > >>> > >>> Hi Ramana, > >>> > >>> The latest version of the opentheory tool (release 20160423) now > >>> includes support for > >>> > >>> interpretation: "file.int" > >>> > >>> lines in theory files, as documented here: > >>> > >>> http://www.gilith.com/research/opentheory/theory.html > >>> > >>> It's lightly tested, so please let me know if you discover anything > >>> odd with the new feature. > >>> > >>> Cheers, > >>> > >>> Joe > >>> > >>> On Wed, Apr 20, 2016 at 9:37 PM, Ramana Kumar > >>> wrote: > >>> > Cool. Thanks! > >>> > > >>> > On 21 April 2016 at 02:40, Joe Leslie-Hurd wrote: > >>> >> > >>> >> By the way, I am working on adding this feature, but for various > >>> >> technical reasons of how the code is structured it's turning out to > be > >>> >> non-trivial. I'll let you know when the feature is added. > >>> >> > >>> >> Cheers, > >>> >> > >>> >> Joe > >>> >> > >>> >> On Sun, Apr 3, 2016 at 10:16 PM, Joe Leslie-Hurd > >>> >> wrote: > >>> >> > Sure thing, I'll work on adding this feature. > >>> >> > > >>> >> > Cheers, > >>> >> > > >>> >> > Joe > >>> >> > > >>> >> > On Fri, Apr 1, 2016 at 3:41 PM, Ramana Kumar < > ramana at member.fsf.org> > >>> >> > wrote: > >>> >> >> Hi Joe, > >>> >> >> > >>> >> >> I would like to reopen this request. It seems like I'm going to > be > >>> >> >> copying > >>> >> >> interpretations around a lot again. > >>> >> >> > >>> >> >> Cheers, > >>> >> >> Ramana > >>> >> >> > >>> >> >> On 4 March 2016 at 12:14, Ramana Kumar > >>> >> >> wrote: > >>> >> >>> > >>> >> >>> Hi Joe, > >>> >> >>> > >>> >> >>> It turns out this is not so urgent for me since Michael and I > came > >>> >> >>> up > >>> >> >>> with > >>> >> >>> another method: > >>> >> >>> Put all the article-combination stuff into one file > >>> >> >>> uninterpreted.thy > >>> >> >>> (main block is a union), then turn that into uninterpreted.art, > and > >>> >> >>> finally > >>> >> >>> do the interpretation all at once (so it only appears in one > file) > >>> >> >>> in > >>> >> >>> interpreted.thy, whose main block is an article block for > >>> >> >>> "uninterpreted.art". > >>> >> >>> > >>> >> >>> However, interpretations from files would probably still be good > >>> >> >>> for > >>> >> >>> other > >>> >> >>> scenarios. I would tweak your suggested syntax to use > >>> >> >>> "interpretation" > >>> >> >>> rather than "interpret-file", to match "article" (which also > takes > >>> >> >>> a > >>> >> >>> filename). > >>> >> >>> > >>> >> >>> Cheers, > >>> >> >>> Ramana > >>> >> >>> > >>> >> >>> On 5 March 2016 at 05:51, Joe Leslie-Hurd > wrote: > >>> >> >>>> > >>> >> >>>> Hi Ramana, > >>> >> >>>> > >>> >> >>>> I agree with you that it would be good for theory files to > support > >>> >> >>>> pulling in interpretations from files. How about the following > >>> >> >>>> syntax: > >>> >> >>>> > >>> >> >>>> interpret-file: "file.int" > >>> >> >>>> > >>> >> >>>> inside a theory block? It probably makes sense to allow > multiple > >>> >> >>>> of > >>> >> >>>> these, just like multiple > >>> >> >>>> > >>> >> >>>> interpret: type/const "X" as "Y" > >>> >> >>>> > >>> >> >>>> lines are allowed, but raise an error if the same symbol is > >>> >> >>>> interpreted in multiple ways. > >>> >> >>>> > >>> >> >>>> Cheers, > >>> >> >>>> > >>> >> >>>> Joe > >>> >> >>>> > >>> >> >>>> On Thu, Mar 3, 2016 at 4:21 PM, Ramana Kumar > >>> >> >>>> > >>> >> >>>> wrote: > >>> >> >>>> > Is it possible to include an interpretation in a theory file, > >>> >> >>>> > rather > >>> >> >>>> > than > >>> >> >>>> > having to write it out inline? Since I sometimes want to > include > >>> >> >>>> > a > >>> >> >>>> > rather > >>> >> >>>> > large interpretation within multiple blocks within the same > >>> >> >>>> > theory > >>> >> >>>> > file, I > >>> >> >>>> > end up having to write a template file and then generate the > >>> >> >>>> > real > >>> >> >>>> > .thy > >>> >> >>>> > file > >>> >> >>>> > from that, to avoid lots of copy-pasting. Is mine the > >>> >> >>>> > recommended > >>> >> >>>> > approach, > >>> >> >>>> > or is there a better way? > >>> >> >>>> > > >>> >> >>>> > _______________________________________________ > >>> >> >>>> > 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 > >>> >> >>> > >>> >> >>> > >>> >> >> > >>> >> >> > >>> >> >> _______________________________________________ > >>> >> >> 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 > >>> > > >>> > > >>> > > >>> > _______________________________________________ > >>> > 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 > >> > >> > >> > >> _______________________________________________ > >> 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 Sun May 8 02:37:23 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Sun, 8 May 2016 12:37:23 +1000 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi, I wanted to check if there was further interest in continuing this discussion from last month. The reason is that I am putting together a lot of OpenTheory packages based on theories made with the HOL theorem prover, and I would like it if this work could fit together nicely with other OpenTheory packages rather than living in its own universe (and perpetuating the problem of fragmentation). I think the theories I'm looking into (n-bit words, floating point numbers, real numbers, integers, rings, streams, quotients, ...) should all ultimately end up within the Standard Library. But to get there would I imagine require substantial coordination with the designers of the OpenTheory standard library, and other interested community members. I am also looking for technical advice on how to interface with the existing theories in the Gilith repo that seem to cover some of those topics. Cheers, Ramana On 13 April 2016 at 17:15, Ramana Kumar wrote: > Data.List.unzip works as a replacement for list.UNZIP. However, I will > hold back for a bit on making a new version of hol-base in case there are > further improvements arising from this thread. > > On 13 April 2016 at 15:38, Konrad Slind wrote: > >> Re: MAP2 in HOL4. This is an example of an underspecified function. I >> recall having >> to redefine map2 to completely specify it in order to get it through the >> HOL-->CakeML translator. >> >> So, presumably, different systems can and will define common partial >> functions differently, as >> either underspecified or completely specified. Is there an OpenTheory >> policy on this, for >> its standard library? >> >> Konrad. >> >> >> On Tue, Apr 12, 2016 at 11:56 PM, Ramana Kumar >> wrote: >> >>> It looks like list.ZIP can't be mapped to Data.List.zip because the >>> latter is curried. But I'm still looking into unzip. >>> >>> On 13 April 2016 at 13:56, Ramana Kumar wrote: >>> >>>> The HOL4 base library has its own version of constants like >>>> Data.List.take and Number.Natural.- because it needs to prove theorems like: >>>> >>>> ? length (list.TAKE n xs) = if n ? length xs then n else length xs >>>> >>>> ? (?m. arithmetic.- 0 m = 0) ? >>>> ?m n. >>>> arithmetic.- (suc m) n = if m < n then 0 else suc (arithmetic.- m n >>>> ) >>>> I don't think these theorems are provable using the OpenTheory standard >>>> library versions of those constants. >>>> >>>> However, I don't know whether Data.List.unzip suffers from this >>>> problem. If not, then the HOL4 base package should be updated to use the >>>> standard library constant. It would be helpful if you could make a list of >>>> any other similar updates that should be made. >>>> >>>> I don't think the current OpenTheory standard library base contains >>>> theories that every HOL theorem prover supports. There are constants like >>>> Data.List.nub, for example, which are not supported by HOL4. I'm not >>>> entirely sure whether being the intersection of what every HOL theorem >>>> prover supports is a good goal, but if that is the rule it should at least >>>> be followed :) >>>> >>>> However, my question was not solely about the base package, but about >>>> the naming scheme for the standard library. If there are useful constants >>>> from other theorem provers (like, say, HOL4's list.GENLIST or list.MAP2), I >>>> think their name and characterising theorems should be fit into the >>>> OpenTheory namespace (Data.List, for example) in a standardised way, even >>>> if they don't make it into the base package itself. What do you think of >>>> that? >>>> >>>> I envision OpenTheory being used for the twin goals of portability >>>> (where being an intersection is good) and designing a rich, cleanly >>>> organised, useful standard library of HOL theorems (where being a union is >>>> good). These activities can happen simultaneously in different OpenTheory >>>> standard packages. >>>> >>>> On 13 April 2016 at 04:11, Joe Leslie-Hurd wrote: >>>> >>>>> Hi Ramana, >>>>> >>>>> The intent is for the standard theory library to always be evolving, >>>>> but slowly, because it's supposed to contain the base theories that >>>>> *every* HOL theorem prover supports. >>>>> >>>>> Looking through the theory I see a lot of defined constants that also >>>>> occur in the OpenTheory standard library (e.g., list.UNZIP), and I was >>>>> wondering why the HOL4 base theory has its own version? >>>>> >>>>> Cheers, >>>>> >>>>> Joe >>>>> >>>>> On Sun, Apr 10, 2016 at 1:54 PM, Ramana Kumar >>>>> wrote: >>>>> > Hi Joe, >>>>> > >>>>> > You will have seen that the HOL developers have uploaded a package >>>>> called >>>>> > hol-base to the Gilith repo. The purpose of this package is twofold: >>>>> > >>>>> > It proves many useful theorems as found in the basic libraries of >>>>> the HOL >>>>> > theorem prover. >>>>> > It serves to satisfy the assumptions of further theories developed >>>>> in the >>>>> > HOL theorem prover, by proving those assumptions using only the >>>>> theorems of >>>>> > the OpenTheory standard library base package. >>>>> > >>>>> > For purpose 1 in particular, it seems to me that many of the >>>>> constants >>>>> > defined by hol-base would benefit from residing in an appropriate >>>>> place in >>>>> > OpenTheory's namespace hierarchy, and indeed some of the proofs from >>>>> > hol-base might beneficially be moved into the base package itself. >>>>> > (Currently, all constants defined by hol-base are in their own >>>>> namespace.) >>>>> > >>>>> > Is the design of the standard library still evolving, and is it open >>>>> to >>>>> > extension? Would you be willing to copy over any useful-looking >>>>> constants? >>>>> > And/or settle on some namespace decisions? >>>>> > >>>>> > Cheers, >>>>> > Ramana >>>>> > >>>>> > _______________________________________________ >>>>> > 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 >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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 Mon May 9 02:09:24 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Mon, 9 May 2016 12:09:24 +1000 Subject: [opentheory-users] Print unsatisfied assumptions Message-ID: Hi, How can I get the unsatisfied assumptions of a theory in article format? I know about the info --assumptions option, but it prints _all_ assumptions, including the satisfied ones. The only way I have found so far to do it is to create a fake package that imports all the required packages and print the assumptions of that. But it's rather cumbersome to do so. Especially because importing the required packages also means figuring out all their dependencies and recreating them as blocks within the theory file in the right order. I know the opentheory tool knows how to calculate just the unsatisfied assumptions. How can I get them out of it? Cheers, Ramana -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Tue May 10 04:07:03 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 10 May 2016 14:07:03 +1000 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: It looks like Number.Real.inv and realax$inv will suffer from the same problem, since in HOL4 we can prove inv 0 = 0. On 13 April 2016 at 15:38, Konrad Slind wrote: > Re: MAP2 in HOL4. This is an example of an underspecified function. I > recall having > to redefine map2 to completely specify it in order to get it through the > HOL-->CakeML translator. > > So, presumably, different systems can and will define common partial > functions differently, as > either underspecified or completely specified. Is there an OpenTheory > policy on this, for > its standard library? > > Konrad. > > > On Tue, Apr 12, 2016 at 11:56 PM, Ramana Kumar > wrote: > >> It looks like list.ZIP can't be mapped to Data.List.zip because the >> latter is curried. But I'm still looking into unzip. >> >> On 13 April 2016 at 13:56, Ramana Kumar wrote: >> >>> The HOL4 base library has its own version of constants like >>> Data.List.take and Number.Natural.- because it needs to prove theorems like: >>> >>> ? length (list.TAKE n xs) = if n ? length xs then n else length xs >>> >>> ? (?m. arithmetic.- 0 m = 0) ? >>> ?m n. >>> arithmetic.- (suc m) n = if m < n then 0 else suc (arithmetic.- m n) >>> I don't think these theorems are provable using the OpenTheory standard >>> library versions of those constants. >>> >>> However, I don't know whether Data.List.unzip suffers from this problem. >>> If not, then the HOL4 base package should be updated to use the standard >>> library constant. It would be helpful if you could make a list of any other >>> similar updates that should be made. >>> >>> I don't think the current OpenTheory standard library base contains >>> theories that every HOL theorem prover supports. There are constants like >>> Data.List.nub, for example, which are not supported by HOL4. I'm not >>> entirely sure whether being the intersection of what every HOL theorem >>> prover supports is a good goal, but if that is the rule it should at least >>> be followed :) >>> >>> However, my question was not solely about the base package, but about >>> the naming scheme for the standard library. If there are useful constants >>> from other theorem provers (like, say, HOL4's list.GENLIST or list.MAP2), I >>> think their name and characterising theorems should be fit into the >>> OpenTheory namespace (Data.List, for example) in a standardised way, even >>> if they don't make it into the base package itself. What do you think of >>> that? >>> >>> I envision OpenTheory being used for the twin goals of portability >>> (where being an intersection is good) and designing a rich, cleanly >>> organised, useful standard library of HOL theorems (where being a union is >>> good). These activities can happen simultaneously in different OpenTheory >>> standard packages. >>> >>> On 13 April 2016 at 04:11, Joe Leslie-Hurd wrote: >>> >>>> Hi Ramana, >>>> >>>> The intent is for the standard theory library to always be evolving, >>>> but slowly, because it's supposed to contain the base theories that >>>> *every* HOL theorem prover supports. >>>> >>>> Looking through the theory I see a lot of defined constants that also >>>> occur in the OpenTheory standard library (e.g., list.UNZIP), and I was >>>> wondering why the HOL4 base theory has its own version? >>>> >>>> Cheers, >>>> >>>> Joe >>>> >>>> On Sun, Apr 10, 2016 at 1:54 PM, Ramana Kumar >>>> wrote: >>>> > Hi Joe, >>>> > >>>> > You will have seen that the HOL developers have uploaded a package >>>> called >>>> > hol-base to the Gilith repo. The purpose of this package is twofold: >>>> > >>>> > It proves many useful theorems as found in the basic libraries of the >>>> HOL >>>> > theorem prover. >>>> > It serves to satisfy the assumptions of further theories developed in >>>> the >>>> > HOL theorem prover, by proving those assumptions using only the >>>> theorems of >>>> > the OpenTheory standard library base package. >>>> > >>>> > For purpose 1 in particular, it seems to me that many of the constants >>>> > defined by hol-base would benefit from residing in an appropriate >>>> place in >>>> > OpenTheory's namespace hierarchy, and indeed some of the proofs from >>>> > hol-base might beneficially be moved into the base package itself. >>>> > (Currently, all constants defined by hol-base are in their own >>>> namespace.) >>>> > >>>> > Is the design of the standard library still evolving, and is it open >>>> to >>>> > extension? Would you be willing to copy over any useful-looking >>>> constants? >>>> > And/or settle on some namespace decisions? >>>> > >>>> > Cheers, >>>> > Ramana >>>> > >>>> > _______________________________________________ >>>> > 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 >>>> >>> >>> >> >> _______________________________________________ >> 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 joe at gilith.com Tue May 10 06:04:55 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 9 May 2016 23:04:55 -0700 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi Ramana, Despite the radio silence, I have been thinking about your question off and on since you asked it. The essential problem is that the different HOL theorem provers have slightly different definitions of fundamental constants, and so all the theories that are built on top of them are incompatible with other theorem provers. The standard theory library uploaded to the Gilith OpenTheory repo is my attempt at defining a common base that is implemented by all theorem provers, but it is imperfect in several ways: 1. It defines constants (such as Data.List.nub) that are not implemented in all the HOL theorem provers. 2. It defines constants (such as Data.List.zip) that exist in some HOL theorem provers with a different type. 3. It defines constants (such as Number.Real.inv) that are underspecified compared to their definitions in some HOL theorem provers. When we are reading an OpenTheory proof into a HOL theorem prover, then I don't believe any of these imperfections present any real obstacle: 1. If the proof relies on Data.List.nub, then this can simply be defined in the theorem prover. As you rightly say, such constants shouldn't really be part of the standard theory library, but I believe there are few enough of them that we can just add to the theorem provers. 2. In principle the OpenTheory interface in the HOL theorem prover would be able to translate constants from one type to an isomorphic one. One way to do this would be to define the OpenTheory versions of the constants in terms of the native ones and then "clean up" the resulting theorems by replacing the OpenTheory versions of the constants by expanding their definitions. 3. The OpenTheory proof will rely on fewer properties of such constants than are available in the native version, so the proof will go through. However, when creating OpenTheory proofs from native theories, then (3) appears to be a real problem. In my work I've tried to create a body of theories that rely only on the underspecified properties of such constants, but when I tried to translate some existing HOL Light proofs I found it hard going (I think I was trying to eliminate the saturated subtraction property: !n. 0 - n = 0). Do you have any ideas for how to overcome obstacle (3) so that we can start to build up a body of theories that can be read into any HOL theorem prover? Cheers, Joe On Sat, May 7, 2016 at 7:37 PM, Ramana Kumar wrote: > Hi, > > I wanted to check if there was further interest in continuing this > discussion from last month. > > The reason is that I am putting together a lot of OpenTheory packages based > on theories made with the HOL theorem prover, and I would like it if this > work could fit together nicely with other OpenTheory packages rather than > living in its own universe (and perpetuating the problem of fragmentation). > > I think the theories I'm looking into (n-bit words, floating point numbers, > real numbers, integers, rings, streams, quotients, ...) should all > ultimately end up within the Standard Library. But to get there would I > imagine require substantial coordination with the designers of the > OpenTheory standard library, and other interested community members. I am > also looking for technical advice on how to interface with the existing > theories in the Gilith repo that seem to cover some of those topics. > > Cheers, > Ramana > > On 13 April 2016 at 17:15, Ramana Kumar wrote: >> >> Data.List.unzip works as a replacement for list.UNZIP. However, I will >> hold back for a bit on making a new version of hol-base in case there are >> further improvements arising from this thread. >> >> On 13 April 2016 at 15:38, Konrad Slind wrote: >>> >>> Re: MAP2 in HOL4. This is an example of an underspecified function. I >>> recall having >>> to redefine map2 to completely specify it in order to get it through the >>> HOL-->CakeML translator. >>> >>> So, presumably, different systems can and will define common partial >>> functions differently, as >>> either underspecified or completely specified. Is there an OpenTheory >>> policy on this, for >>> its standard library? >>> >>> Konrad. >>> >>> >>> On Tue, Apr 12, 2016 at 11:56 PM, Ramana Kumar >>> wrote: >>>> >>>> It looks like list.ZIP can't be mapped to Data.List.zip because the >>>> latter is curried. But I'm still looking into unzip. >>>> >>>> On 13 April 2016 at 13:56, Ramana Kumar wrote: >>>>> >>>>> The HOL4 base library has its own version of constants like >>>>> Data.List.take and Number.Natural.- because it needs to prove theorems like: >>>>> >>>>> ? length (list.TAKE n xs) = if n ? length xs then n else length xs >>>>> >>>>> ? (?m. arithmetic.- 0 m = 0) ? >>>>> ?m n. >>>>> arithmetic.- (suc m) n = if m < n then 0 else suc (arithmetic.- m >>>>> n) >>>>> >>>>> I don't think these theorems are provable using the OpenTheory standard >>>>> library versions of those constants. >>>>> >>>>> However, I don't know whether Data.List.unzip suffers from this >>>>> problem. If not, then the HOL4 base package should be updated to use the >>>>> standard library constant. It would be helpful if you could make a list of >>>>> any other similar updates that should be made. >>>>> >>>>> I don't think the current OpenTheory standard library base contains >>>>> theories that every HOL theorem prover supports. There are constants like >>>>> Data.List.nub, for example, which are not supported by HOL4. I'm not >>>>> entirely sure whether being the intersection of what every HOL theorem >>>>> prover supports is a good goal, but if that is the rule it should at least >>>>> be followed :) >>>>> >>>>> However, my question was not solely about the base package, but about >>>>> the naming scheme for the standard library. If there are useful constants >>>>> from other theorem provers (like, say, HOL4's list.GENLIST or list.MAP2), I >>>>> think their name and characterising theorems should be fit into the >>>>> OpenTheory namespace (Data.List, for example) in a standardised way, even if >>>>> they don't make it into the base package itself. What do you think of that? >>>>> >>>>> I envision OpenTheory being used for the twin goals of portability >>>>> (where being an intersection is good) and designing a rich, cleanly >>>>> organised, useful standard library of HOL theorems (where being a union is >>>>> good). These activities can happen simultaneously in different OpenTheory >>>>> standard packages. >>>>> >>>>> On 13 April 2016 at 04:11, Joe Leslie-Hurd wrote: >>>>>> >>>>>> Hi Ramana, >>>>>> >>>>>> The intent is for the standard theory library to always be evolving, >>>>>> but slowly, because it's supposed to contain the base theories that >>>>>> *every* HOL theorem prover supports. >>>>>> >>>>>> Looking through the theory I see a lot of defined constants that also >>>>>> occur in the OpenTheory standard library (e.g., list.UNZIP), and I was >>>>>> wondering why the HOL4 base theory has its own version? >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Joe >>>>>> >>>>>> On Sun, Apr 10, 2016 at 1:54 PM, Ramana Kumar >>>>>> wrote: >>>>>> > Hi Joe, >>>>>> > >>>>>> > You will have seen that the HOL developers have uploaded a package >>>>>> > called >>>>>> > hol-base to the Gilith repo. The purpose of this package is twofold: >>>>>> > >>>>>> > It proves many useful theorems as found in the basic libraries of >>>>>> > the HOL >>>>>> > theorem prover. >>>>>> > It serves to satisfy the assumptions of further theories developed >>>>>> > in the >>>>>> > HOL theorem prover, by proving those assumptions using only the >>>>>> > theorems of >>>>>> > the OpenTheory standard library base package. >>>>>> > >>>>>> > For purpose 1 in particular, it seems to me that many of the >>>>>> > constants >>>>>> > defined by hol-base would benefit from residing in an appropriate >>>>>> > place in >>>>>> > OpenTheory's namespace hierarchy, and indeed some of the proofs from >>>>>> > hol-base might beneficially be moved into the base package itself. >>>>>> > (Currently, all constants defined by hol-base are in their own >>>>>> > namespace.) >>>>>> > >>>>>> > Is the design of the standard library still evolving, and is it open >>>>>> > to >>>>>> > extension? Would you be willing to copy over any useful-looking >>>>>> > constants? >>>>>> > And/or settle on some namespace decisions? >>>>>> > >>>>>> > Cheers, >>>>>> > Ramana >>>>>> > >>>>>> > _______________________________________________ >>>>>> > 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 >>>>> >>>>> >>>> >>>> >>>> _______________________________________________ >>>> 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 >>> >> > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From joe at gilith.com Tue May 10 06:08:59 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 9 May 2016 23:08:59 -0700 Subject: [opentheory-users] Print unsatisfied assumptions In-Reply-To: References: Message-ID: I can't think of any way of persuading the existing opentheory tool to give you this functionality, except in the way you describe. I'd be happy to add the functionality to the tool, but it may take a little while. As a matter of curiosity, what is your use-case for this functionality? Cheers, Joe On Sun, May 8, 2016 at 7:09 PM, Ramana Kumar wrote: > Hi, > > How can I get the unsatisfied assumptions of a theory in article format? > > I know about the info --assumptions option, but it prints _all_ assumptions, > including the satisfied ones. > > The only way I have found so far to do it is to create a fake package that > imports all the required packages and print the assumptions of that. But > it's rather cumbersome to do so. Especially because importing the required > packages also means figuring out all their dependencies and recreating them > as blocks within the theory file in the right order. > > I know the opentheory tool knows how to calculate just the unsatisfied > assumptions. How can I get them out of it? > > Cheers, > Ramana > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From ramana at member.fsf.org Tue May 10 06:58:56 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 10 May 2016 16:58:56 +1000 Subject: [opentheory-users] Print unsatisfied assumptions In-Reply-To: References: Message-ID: Abstractly, my use-case is: I have a package A that develops some concepts that are already in a standard library package, B. A is developed from scratch, but goes much further than B. I want to present A as if it were based on B, rather than developed from scratch. So, I pull out the foundations from A, replace them by B, and then I want to see what remaining foundational assumptions need to be proved manually (starting from what is provided by B). On 10 May 2016 at 16:08, Joe Leslie-Hurd wrote: > I can't think of any way of persuading the existing opentheory tool to > give you this functionality, except in the way you describe. > > I'd be happy to add the functionality to the tool, but it may take a > little while. > > As a matter of curiosity, what is your use-case for this functionality? > > Cheers, > > Joe > > On Sun, May 8, 2016 at 7:09 PM, Ramana Kumar > wrote: > > Hi, > > > > How can I get the unsatisfied assumptions of a theory in article format? > > > > I know about the info --assumptions option, but it prints _all_ > assumptions, > > including the satisfied ones. > > > > The only way I have found so far to do it is to create a fake package > that > > imports all the required packages and print the assumptions of that. But > > it's rather cumbersome to do so. Especially because importing the > required > > packages also means figuring out all their dependencies and recreating > them > > as blocks within the theory file in the right order. > > > > I know the opentheory tool knows how to calculate just the unsatisfied > > assumptions. How can I get them out of it? > > > > Cheers, > > Ramana > > > > > > _______________________________________________ > > 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 Wed May 11 06:40:12 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Wed, 11 May 2016 16:40:12 +1000 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi Joe, Thanks for your reply, which expresses the problem clearly. There are the three issues with the standard theory library you listed, and there are two perspectives to consider: reading an OpenTheory proof into a theorem prover ("reading"), and creating an OpenTheory proof from a native theory ("creating"). Before considering issue (3), I want clarify what to do about the other two issues from the creating perspective. For (1), there is no problem since the extra constant can be ignored. For (2), I think some variation on your solution for the reading perspective could work. There are three pieces to the solution: A: Define the native version of the constant B: Prove an equation relating the native version to the OpenTheory version C: Use the theorem from B to rewrite theorems mentioning the native constant into theorems mentioning only the OpenTheory version of the constant. How should responsibility for these tasks be divided between readers and creators? Initially, in the creator role, I am tempted to do only A, and leave B and C to the readers. I would expect you to eventually want all three to be done by the creator. I think there is some variation in how desirable C might be for different readers. Now for issue (3) from the creating perspective. I agree that it is a real problem. I have a couple of ideas for possible solutions. 0. If the constant only has one natural candidate for how it might be overspecified, and all theorem provers overspecify it that way, simply do so in the OpenTheory standard library too. 1. Provide multiple versions of the constant in the standard library for each of the natural ways of overspecifying it, and prove theorems relating them (under appropriate conditions). Theorems that can be stated using the underspecified version should be (and readers should prefer these), but theorems that require overspecification can also be included (and readers can handle these as they do issue (2)). Indeed, I think issue (3) is a variant of issue (2) where we cannot prove an unconditional equation between different versions of the constants, but where we can still prove a conditional one. Do you have any other ideas for how to deal with these issues? Cheers, Ramana On 10 May 2016 at 16:04, Joe Leslie-Hurd wrote: > Hi Ramana, > > Despite the radio silence, I have been thinking about your question > off and on since you asked it. > > The essential problem is that the different HOL theorem provers have > slightly different definitions of fundamental constants, and so all > the theories that are built on top of them are incompatible with other > theorem provers. > > The standard theory library uploaded to the Gilith OpenTheory repo is > my attempt at defining a common base that is implemented by all > theorem provers, but it is imperfect in several ways: > > 1. It defines constants (such as Data.List.nub) that are not > implemented in all the HOL theorem provers. > 2. It defines constants (such as Data.List.zip) that exist in some HOL > theorem provers with a different type. > 3. It defines constants (such as Number.Real.inv) that are > underspecified compared to their definitions in some HOL theorem > provers. > > When we are reading an OpenTheory proof into a HOL theorem prover, > then I don't believe any of these imperfections present any real > obstacle: > > 1. If the proof relies on Data.List.nub, then this can simply be > defined in the theorem prover. As you rightly say, such constants > shouldn't really be part of the standard theory library, but I believe > there are few enough of them that we can just add to the theorem > provers. > 2. In principle the OpenTheory interface in the HOL theorem prover > would be able to translate constants from one type to an isomorphic > one. One way to do this would be to define the OpenTheory versions of > the constants in terms of the native ones and then "clean up" the > resulting theorems by replacing the OpenTheory versions of the > constants by expanding their definitions. > 3. The OpenTheory proof will rely on fewer properties of such > constants than are available in the native version, so the proof will > go through. > > However, when creating OpenTheory proofs from native theories, then > (3) appears to be a real problem. In my work I've tried to create a > body of theories that rely only on the underspecified properties of > such constants, but when I tried to translate some existing HOL Light > proofs I found it hard going (I think I was trying to eliminate the > saturated subtraction property: !n. 0 - n = 0). > > Do you have any ideas for how to overcome obstacle (3) so that we can > start to build up a body of theories that can be read into any HOL > theorem prover? > > Cheers, > > Joe > > > On Sat, May 7, 2016 at 7:37 PM, Ramana Kumar > wrote: > > Hi, > > > > I wanted to check if there was further interest in continuing this > > discussion from last month. > > > > The reason is that I am putting together a lot of OpenTheory packages > based > > on theories made with the HOL theorem prover, and I would like it if this > > work could fit together nicely with other OpenTheory packages rather than > > living in its own universe (and perpetuating the problem of > fragmentation). > > > > I think the theories I'm looking into (n-bit words, floating point > numbers, > > real numbers, integers, rings, streams, quotients, ...) should all > > ultimately end up within the Standard Library. But to get there would I > > imagine require substantial coordination with the designers of the > > OpenTheory standard library, and other interested community members. I am > > also looking for technical advice on how to interface with the existing > > theories in the Gilith repo that seem to cover some of those topics. > > > > Cheers, > > Ramana > > > > On 13 April 2016 at 17:15, Ramana Kumar wrote: > >> > >> Data.List.unzip works as a replacement for list.UNZIP. However, I will > >> hold back for a bit on making a new version of hol-base in case there > are > >> further improvements arising from this thread. > >> > >> On 13 April 2016 at 15:38, Konrad Slind wrote: > >>> > >>> Re: MAP2 in HOL4. This is an example of an underspecified function. I > >>> recall having > >>> to redefine map2 to completely specify it in order to get it through > the > >>> HOL-->CakeML translator. > >>> > >>> So, presumably, different systems can and will define common partial > >>> functions differently, as > >>> either underspecified or completely specified. Is there an OpenTheory > >>> policy on this, for > >>> its standard library? > >>> > >>> Konrad. > >>> > >>> > >>> On Tue, Apr 12, 2016 at 11:56 PM, Ramana Kumar > >>> wrote: > >>>> > >>>> It looks like list.ZIP can't be mapped to Data.List.zip because the > >>>> latter is curried. But I'm still looking into unzip. > >>>> > >>>> On 13 April 2016 at 13:56, Ramana Kumar > wrote: > >>>>> > >>>>> The HOL4 base library has its own version of constants like > >>>>> Data.List.take and Number.Natural.- because it needs to prove > theorems like: > >>>>> > >>>>> ? length (list.TAKE n xs) = if n ? length xs then n else length xs > >>>>> > >>>>> ? (?m. arithmetic.- 0 m = 0) ? > >>>>> ?m n. > >>>>> arithmetic.- (suc m) n = if m < n then 0 else suc (arithmetic.- m > >>>>> n) > >>>>> > >>>>> I don't think these theorems are provable using the OpenTheory > standard > >>>>> library versions of those constants. > >>>>> > >>>>> However, I don't know whether Data.List.unzip suffers from this > >>>>> problem. If not, then the HOL4 base package should be updated to use > the > >>>>> standard library constant. It would be helpful if you could make a > list of > >>>>> any other similar updates that should be made. > >>>>> > >>>>> I don't think the current OpenTheory standard library base contains > >>>>> theories that every HOL theorem prover supports. There are constants > like > >>>>> Data.List.nub, for example, which are not supported by HOL4. I'm not > >>>>> entirely sure whether being the intersection of what every HOL > theorem > >>>>> prover supports is a good goal, but if that is the rule it should at > least > >>>>> be followed :) > >>>>> > >>>>> However, my question was not solely about the base package, but about > >>>>> the naming scheme for the standard library. If there are useful > constants > >>>>> from other theorem provers (like, say, HOL4's list.GENLIST or > list.MAP2), I > >>>>> think their name and characterising theorems should be fit into the > >>>>> OpenTheory namespace (Data.List, for example) in a standardised way, > even if > >>>>> they don't make it into the base package itself. What do you think > of that? > >>>>> > >>>>> I envision OpenTheory being used for the twin goals of portability > >>>>> (where being an intersection is good) and designing a rich, cleanly > >>>>> organised, useful standard library of HOL theorems (where being a > union is > >>>>> good). These activities can happen simultaneously in different > OpenTheory > >>>>> standard packages. > >>>>> > >>>>> On 13 April 2016 at 04:11, Joe Leslie-Hurd wrote: > >>>>>> > >>>>>> Hi Ramana, > >>>>>> > >>>>>> The intent is for the standard theory library to always be evolving, > >>>>>> but slowly, because it's supposed to contain the base theories that > >>>>>> *every* HOL theorem prover supports. > >>>>>> > >>>>>> Looking through the theory I see a lot of defined constants that > also > >>>>>> occur in the OpenTheory standard library (e.g., list.UNZIP), and I > was > >>>>>> wondering why the HOL4 base theory has its own version? > >>>>>> > >>>>>> Cheers, > >>>>>> > >>>>>> Joe > >>>>>> > >>>>>> On Sun, Apr 10, 2016 at 1:54 PM, Ramana Kumar < > ramana at member.fsf.org> > >>>>>> wrote: > >>>>>> > Hi Joe, > >>>>>> > > >>>>>> > You will have seen that the HOL developers have uploaded a package > >>>>>> > called > >>>>>> > hol-base to the Gilith repo. The purpose of this package is > twofold: > >>>>>> > > >>>>>> > It proves many useful theorems as found in the basic libraries of > >>>>>> > the HOL > >>>>>> > theorem prover. > >>>>>> > It serves to satisfy the assumptions of further theories developed > >>>>>> > in the > >>>>>> > HOL theorem prover, by proving those assumptions using only the > >>>>>> > theorems of > >>>>>> > the OpenTheory standard library base package. > >>>>>> > > >>>>>> > For purpose 1 in particular, it seems to me that many of the > >>>>>> > constants > >>>>>> > defined by hol-base would benefit from residing in an appropriate > >>>>>> > place in > >>>>>> > OpenTheory's namespace hierarchy, and indeed some of the proofs > from > >>>>>> > hol-base might beneficially be moved into the base package itself. > >>>>>> > (Currently, all constants defined by hol-base are in their own > >>>>>> > namespace.) > >>>>>> > > >>>>>> > Is the design of the standard library still evolving, and is it > open > >>>>>> > to > >>>>>> > extension? Would you be willing to copy over any useful-looking > >>>>>> > constants? > >>>>>> > And/or settle on some namespace decisions? > >>>>>> > > >>>>>> > Cheers, > >>>>>> > Ramana > >>>>>> > > >>>>>> > _______________________________________________ > >>>>>> > 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 > >>>>> > >>>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> 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 > >>> > >> > > > > > > _______________________________________________ > > 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 joe at gilith.com Wed May 11 23:19:13 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 11 May 2016 16:19:13 -0700 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi Ramana, The problem I found with totalized constants is that the extra properties (e.g., inv 0 = 0) quickly infect a whole theory, which makes it useless for reading into an environment where the constant is defined differently. I'm loath to totalize any of the constants in the OpenTheory standard library just because there's an open world assumption that new environments might come along---beyond the HOL4, HOL Light and ProofPower theorem provers---with different policies on whether and how to totalize constants, but would still be able to read in current OpenTheory theories with underspecified constants. >From your perspective as a theory creator I say just create theories in OpenTheory format that depend on your hol-base theory with its HOL4 flavour of constants. Incidentally, you also asked about naming schemes in the hol-base theory, and I think it is set up perfectly with everything under a HOL4 namespace. Within that you can do whatever makes sense within a HOL4 context, which is the theory name followed by the symbol name. I do the same thing with HOL Light symbols, where there is no notion of theory name so it is even flatter. When the HOL4 theory packages are in place we can assess how feasible and desirable it is to remove their dependency on the hol-base package, so they can be read into any environment. Does that sound reasonable? Cheers, Joe On Tue, May 10, 2016 at 11:40 PM, Ramana Kumar wrote: > Hi Joe, > > Thanks for your reply, which expresses the problem clearly. > There are the three issues with the standard theory library you listed, and > there are two perspectives to consider: reading an OpenTheory proof into a > theorem prover ("reading"), and creating an OpenTheory proof from a native > theory ("creating"). > > Before considering issue (3), I want clarify what to do about the other two > issues from the creating perspective. For (1), there is no problem since the > extra constant can be ignored. For (2), I think some variation on your > solution > for the reading perspective could work. There are three pieces to the > solution: > > A: Define the native version of the constant > B: Prove an equation relating the native version to the OpenTheory version > C: Use the theorem from B to rewrite theorems mentioning the native > constant > into theorems mentioning only the OpenTheory version of the constant. > > How should responsibility for these tasks be divided between readers and > creators? Initially, in the creator role, I am tempted to do only A, and > leave > B and C to the readers. I would expect you to eventually want all three to > be > done by the creator. I think there is some variation in how desirable C > might > be for different readers. > > Now for issue (3) from the creating perspective. I agree that it is a real > problem. I have a couple of ideas for possible solutions. > > 0. If the constant only has one natural candidate for how it might be > overspecified, and all theorem provers overspecify it that way, simply > do > so in the OpenTheory standard library too. > 1. Provide multiple versions of the constant in the standard library for > each > of the natural ways of overspecifying it, and prove theorems relating > them > (under appropriate conditions). Theorems that can be stated using the > underspecified version should be (and readers should prefer these), but > theorems that require overspecification can also be included (and > readers > can handle these as they do issue (2)). > > Indeed, I think issue (3) is a variant of issue (2) where we cannot prove an > unconditional equation between different versions of the constants, but > where > we can still prove a conditional one. > > Do you have any other ideas for how to deal with these issues? > > Cheers, > Ramana > > On 10 May 2016 at 16:04, Joe Leslie-Hurd wrote: >> >> Hi Ramana, >> >> Despite the radio silence, I have been thinking about your question >> off and on since you asked it. >> >> The essential problem is that the different HOL theorem provers have >> slightly different definitions of fundamental constants, and so all >> the theories that are built on top of them are incompatible with other >> theorem provers. >> >> The standard theory library uploaded to the Gilith OpenTheory repo is >> my attempt at defining a common base that is implemented by all >> theorem provers, but it is imperfect in several ways: >> >> 1. It defines constants (such as Data.List.nub) that are not >> implemented in all the HOL theorem provers. >> 2. It defines constants (such as Data.List.zip) that exist in some HOL >> theorem provers with a different type. >> 3. It defines constants (such as Number.Real.inv) that are >> underspecified compared to their definitions in some HOL theorem >> provers. >> >> When we are reading an OpenTheory proof into a HOL theorem prover, >> then I don't believe any of these imperfections present any real >> obstacle: >> >> 1. If the proof relies on Data.List.nub, then this can simply be >> defined in the theorem prover. As you rightly say, such constants >> shouldn't really be part of the standard theory library, but I believe >> there are few enough of them that we can just add to the theorem >> provers. >> 2. In principle the OpenTheory interface in the HOL theorem prover >> would be able to translate constants from one type to an isomorphic >> one. One way to do this would be to define the OpenTheory versions of >> the constants in terms of the native ones and then "clean up" the >> resulting theorems by replacing the OpenTheory versions of the >> constants by expanding their definitions. >> 3. The OpenTheory proof will rely on fewer properties of such >> constants than are available in the native version, so the proof will >> go through. >> >> However, when creating OpenTheory proofs from native theories, then >> (3) appears to be a real problem. In my work I've tried to create a >> body of theories that rely only on the underspecified properties of >> such constants, but when I tried to translate some existing HOL Light >> proofs I found it hard going (I think I was trying to eliminate the >> saturated subtraction property: !n. 0 - n = 0). >> >> Do you have any ideas for how to overcome obstacle (3) so that we can >> start to build up a body of theories that can be read into any HOL >> theorem prover? >> >> Cheers, >> >> Joe >> >> >> On Sat, May 7, 2016 at 7:37 PM, Ramana Kumar >> wrote: >> > Hi, >> > >> > I wanted to check if there was further interest in continuing this >> > discussion from last month. >> > >> > The reason is that I am putting together a lot of OpenTheory packages >> > based >> > on theories made with the HOL theorem prover, and I would like it if >> > this >> > work could fit together nicely with other OpenTheory packages rather >> > than >> > living in its own universe (and perpetuating the problem of >> > fragmentation). >> > >> > I think the theories I'm looking into (n-bit words, floating point >> > numbers, >> > real numbers, integers, rings, streams, quotients, ...) should all >> > ultimately end up within the Standard Library. But to get there would I >> > imagine require substantial coordination with the designers of the >> > OpenTheory standard library, and other interested community members. I >> > am >> > also looking for technical advice on how to interface with the existing >> > theories in the Gilith repo that seem to cover some of those topics. >> > >> > Cheers, >> > Ramana >> > >> > On 13 April 2016 at 17:15, Ramana Kumar wrote: >> >> >> >> Data.List.unzip works as a replacement for list.UNZIP. However, I will >> >> hold back for a bit on making a new version of hol-base in case there >> >> are >> >> further improvements arising from this thread. >> >> >> >> On 13 April 2016 at 15:38, Konrad Slind wrote: >> >>> >> >>> Re: MAP2 in HOL4. This is an example of an underspecified function. I >> >>> recall having >> >>> to redefine map2 to completely specify it in order to get it through >> >>> the >> >>> HOL-->CakeML translator. >> >>> >> >>> So, presumably, different systems can and will define common partial >> >>> functions differently, as >> >>> either underspecified or completely specified. Is there an OpenTheory >> >>> policy on this, for >> >>> its standard library? >> >>> >> >>> Konrad. >> >>> >> >>> >> >>> On Tue, Apr 12, 2016 at 11:56 PM, Ramana Kumar >> >>> wrote: >> >>>> >> >>>> It looks like list.ZIP can't be mapped to Data.List.zip because the >> >>>> latter is curried. But I'm still looking into unzip. >> >>>> >> >>>> On 13 April 2016 at 13:56, Ramana Kumar >> >>>> wrote: >> >>>>> >> >>>>> The HOL4 base library has its own version of constants like >> >>>>> Data.List.take and Number.Natural.- because it needs to prove >> >>>>> theorems like: >> >>>>> >> >>>>> ? length (list.TAKE n xs) = if n ? length xs then n else length xs >> >>>>> >> >>>>> ? (?m. arithmetic.- 0 m = 0) ? >> >>>>> ?m n. >> >>>>> arithmetic.- (suc m) n = if m < n then 0 else suc (arithmetic.- >> >>>>> m >> >>>>> n) >> >>>>> >> >>>>> I don't think these theorems are provable using the OpenTheory >> >>>>> standard >> >>>>> library versions of those constants. >> >>>>> >> >>>>> However, I don't know whether Data.List.unzip suffers from this >> >>>>> problem. If not, then the HOL4 base package should be updated to use >> >>>>> the >> >>>>> standard library constant. It would be helpful if you could make a >> >>>>> list of >> >>>>> any other similar updates that should be made. >> >>>>> >> >>>>> I don't think the current OpenTheory standard library base contains >> >>>>> theories that every HOL theorem prover supports. There are constants >> >>>>> like >> >>>>> Data.List.nub, for example, which are not supported by HOL4. I'm not >> >>>>> entirely sure whether being the intersection of what every HOL >> >>>>> theorem >> >>>>> prover supports is a good goal, but if that is the rule it should at >> >>>>> least >> >>>>> be followed :) >> >>>>> >> >>>>> However, my question was not solely about the base package, but >> >>>>> about >> >>>>> the naming scheme for the standard library. If there are useful >> >>>>> constants >> >>>>> from other theorem provers (like, say, HOL4's list.GENLIST or >> >>>>> list.MAP2), I >> >>>>> think their name and characterising theorems should be fit into the >> >>>>> OpenTheory namespace (Data.List, for example) in a standardised way, >> >>>>> even if >> >>>>> they don't make it into the base package itself. What do you think >> >>>>> of that? >> >>>>> >> >>>>> I envision OpenTheory being used for the twin goals of portability >> >>>>> (where being an intersection is good) and designing a rich, cleanly >> >>>>> organised, useful standard library of HOL theorems (where being a >> >>>>> union is >> >>>>> good). These activities can happen simultaneously in different >> >>>>> OpenTheory >> >>>>> standard packages. >> >>>>> >> >>>>> On 13 April 2016 at 04:11, Joe Leslie-Hurd wrote: >> >>>>>> >> >>>>>> Hi Ramana, >> >>>>>> >> >>>>>> The intent is for the standard theory library to always be >> >>>>>> evolving, >> >>>>>> but slowly, because it's supposed to contain the base theories that >> >>>>>> *every* HOL theorem prover supports. >> >>>>>> >> >>>>>> Looking through the theory I see a lot of defined constants that >> >>>>>> also >> >>>>>> occur in the OpenTheory standard library (e.g., list.UNZIP), and I >> >>>>>> was >> >>>>>> wondering why the HOL4 base theory has its own version? >> >>>>>> >> >>>>>> Cheers, >> >>>>>> >> >>>>>> Joe >> >>>>>> >> >>>>>> On Sun, Apr 10, 2016 at 1:54 PM, Ramana Kumar >> >>>>>> >> >>>>>> wrote: >> >>>>>> > Hi Joe, >> >>>>>> > >> >>>>>> > You will have seen that the HOL developers have uploaded a >> >>>>>> > package >> >>>>>> > called >> >>>>>> > hol-base to the Gilith repo. The purpose of this package is >> >>>>>> > twofold: >> >>>>>> > >> >>>>>> > It proves many useful theorems as found in the basic libraries of >> >>>>>> > the HOL >> >>>>>> > theorem prover. >> >>>>>> > It serves to satisfy the assumptions of further theories >> >>>>>> > developed >> >>>>>> > in the >> >>>>>> > HOL theorem prover, by proving those assumptions using only the >> >>>>>> > theorems of >> >>>>>> > the OpenTheory standard library base package. >> >>>>>> > >> >>>>>> > For purpose 1 in particular, it seems to me that many of the >> >>>>>> > constants >> >>>>>> > defined by hol-base would benefit from residing in an appropriate >> >>>>>> > place in >> >>>>>> > OpenTheory's namespace hierarchy, and indeed some of the proofs >> >>>>>> > from >> >>>>>> > hol-base might beneficially be moved into the base package >> >>>>>> > itself. >> >>>>>> > (Currently, all constants defined by hol-base are in their own >> >>>>>> > namespace.) >> >>>>>> > >> >>>>>> > Is the design of the standard library still evolving, and is it >> >>>>>> > open >> >>>>>> > to >> >>>>>> > extension? Would you be willing to copy over any useful-looking >> >>>>>> > constants? >> >>>>>> > And/or settle on some namespace decisions? >> >>>>>> > >> >>>>>> > Cheers, >> >>>>>> > Ramana >> >>>>>> > >> >>>>>> > _______________________________________________ >> >>>>>> > 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 >> >>>>> >> >>>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> 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 >> >>> >> >> >> > >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From ramana at member.fsf.org Thu May 12 02:27:06 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Thu, 12 May 2016 12:27:06 +1000 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi Joe, Sorry, but I feel like we are talking past each other at the moment. I asked a few questions in my last email which I don't think you addressed. Let me address the concerns in your email first, then I will try to ask my questions again. I agree with you about the value of underspecified constants in the standard library. The source of value is that they put fewer constraints on readers, thereby making theories based on the standard library more widely readable. On creating theories in the HOL4 namespace, and depending on the hol-base package: I see these as interim measures, with my desired goal being that the theorems and additional constants eventually all make it into the standard namespace and depend on a nicely organised, unified, tree of packages. I think we probably agree on that goal, but I'm not sure. What do you say? More generally, my goal is to put together OpenTheory packages that are so compelling in their organisation and coverage, having taken theorems from all the existing HOL provers, that everyone wants to use them. I want to move towards unification and away from fragmentation. I would be sad if OpenTheory simply becomes a mirror of the existing fragmentation and incompatibility between the various theorem prover libraries today. Do you agree with this more general goal? I would like to discuss how to achieve the HOL4-specific goal now, because I think we have enough information to make progress on such a discussion (enough HOL4 packages are already created). (This is in response to "When the HOL4 theory packages are in place...".) Now back to the questions from my previous email: - Do you agree with the three pieces of my solution to issue (2)? How do you think responsibility for those tasks should be divided between readers and creators? - I guess your response "I'm loath to totalize any of the constants..." was mainly to my suggested solution 0 to issue (3). That is a reasonable objection to solution 0. But: What do you think of solution 1, namely, providing multiple versions of constants that can be overspecified (in addition to the underspecified version), together with theorems relating them? Thanks for bearing with me. Cheers, Ramana On 12 May 2016 at 09:19, Joe Leslie-Hurd wrote: > Hi Ramana, > > The problem I found with totalized constants is that the extra > properties (e.g., inv 0 = 0) quickly infect a whole theory, which > makes it useless for reading into an environment where the constant is > defined differently. > > I'm loath to totalize any of the constants in the OpenTheory standard > library just because there's an open world assumption that new > environments might come along---beyond the HOL4, HOL Light and > ProofPower theorem provers---with different policies on whether and > how to totalize constants, but would still be able to read in current > OpenTheory theories with underspecified constants. > > From your perspective as a theory creator I say just create theories > in OpenTheory format that depend on your hol-base theory with its HOL4 > flavour of constants. Incidentally, you also asked about naming > schemes in the hol-base theory, and I think it is set up perfectly > with everything under a HOL4 namespace. Within that you can do > whatever makes sense within a HOL4 context, which is the theory name > followed by the symbol name. I do the same thing with HOL Light > symbols, where there is no notion of theory name so it is even > flatter. > > When the HOL4 theory packages are in place we can assess how feasible > and desirable it is to remove their dependency on the hol-base > package, so they can be read into any environment. > > Does that sound reasonable? > > Cheers, > > Joe > > > On Tue, May 10, 2016 at 11:40 PM, Ramana Kumar > wrote: > > Hi Joe, > > > > Thanks for your reply, which expresses the problem clearly. > > There are the three issues with the standard theory library you listed, > and > > there are two perspectives to consider: reading an OpenTheory proof into > a > > theorem prover ("reading"), and creating an OpenTheory proof from a > native > > theory ("creating"). > > > > Before considering issue (3), I want clarify what to do about the other > two > > issues from the creating perspective. For (1), there is no problem since > the > > extra constant can be ignored. For (2), I think some variation on your > > solution > > for the reading perspective could work. There are three pieces to the > > solution: > > > > A: Define the native version of the constant > > B: Prove an equation relating the native version to the OpenTheory > version > > C: Use the theorem from B to rewrite theorems mentioning the native > > constant > > into theorems mentioning only the OpenTheory version of the > constant. > > > > How should responsibility for these tasks be divided between readers and > > creators? Initially, in the creator role, I am tempted to do only A, and > > leave > > B and C to the readers. I would expect you to eventually want all three > to > > be > > done by the creator. I think there is some variation in how desirable C > > might > > be for different readers. > > > > Now for issue (3) from the creating perspective. I agree that it is a > real > > problem. I have a couple of ideas for possible solutions. > > > > 0. If the constant only has one natural candidate for how it might be > > overspecified, and all theorem provers overspecify it that way, > simply > > do > > so in the OpenTheory standard library too. > > 1. Provide multiple versions of the constant in the standard library > for > > each > > of the natural ways of overspecifying it, and prove theorems > relating > > them > > (under appropriate conditions). Theorems that can be stated using > the > > underspecified version should be (and readers should prefer these), > but > > theorems that require overspecification can also be included (and > > readers > > can handle these as they do issue (2)). > > > > Indeed, I think issue (3) is a variant of issue (2) where we cannot > prove an > > unconditional equation between different versions of the constants, but > > where > > we can still prove a conditional one. > > > > Do you have any other ideas for how to deal with these issues? > > > > Cheers, > > Ramana > > > > On 10 May 2016 at 16:04, Joe Leslie-Hurd wrote: > >> > >> Hi Ramana, > >> > >> Despite the radio silence, I have been thinking about your question > >> off and on since you asked it. > >> > >> The essential problem is that the different HOL theorem provers have > >> slightly different definitions of fundamental constants, and so all > >> the theories that are built on top of them are incompatible with other > >> theorem provers. > >> > >> The standard theory library uploaded to the Gilith OpenTheory repo is > >> my attempt at defining a common base that is implemented by all > >> theorem provers, but it is imperfect in several ways: > >> > >> 1. It defines constants (such as Data.List.nub) that are not > >> implemented in all the HOL theorem provers. > >> 2. It defines constants (such as Data.List.zip) that exist in some HOL > >> theorem provers with a different type. > >> 3. It defines constants (such as Number.Real.inv) that are > >> underspecified compared to their definitions in some HOL theorem > >> provers. > >> > >> When we are reading an OpenTheory proof into a HOL theorem prover, > >> then I don't believe any of these imperfections present any real > >> obstacle: > >> > >> 1. If the proof relies on Data.List.nub, then this can simply be > >> defined in the theorem prover. As you rightly say, such constants > >> shouldn't really be part of the standard theory library, but I believe > >> there are few enough of them that we can just add to the theorem > >> provers. > >> 2. In principle the OpenTheory interface in the HOL theorem prover > >> would be able to translate constants from one type to an isomorphic > >> one. One way to do this would be to define the OpenTheory versions of > >> the constants in terms of the native ones and then "clean up" the > >> resulting theorems by replacing the OpenTheory versions of the > >> constants by expanding their definitions. > >> 3. The OpenTheory proof will rely on fewer properties of such > >> constants than are available in the native version, so the proof will > >> go through. > >> > >> However, when creating OpenTheory proofs from native theories, then > >> (3) appears to be a real problem. In my work I've tried to create a > >> body of theories that rely only on the underspecified properties of > >> such constants, but when I tried to translate some existing HOL Light > >> proofs I found it hard going (I think I was trying to eliminate the > >> saturated subtraction property: !n. 0 - n = 0). > >> > >> Do you have any ideas for how to overcome obstacle (3) so that we can > >> start to build up a body of theories that can be read into any HOL > >> theorem prover? > >> > >> Cheers, > >> > >> Joe > >> > >> > > _______________________________________________ > > 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 Fri May 13 08:45:05 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Fri, 13 May 2016 18:45:05 +1000 Subject: [opentheory-users] Retract upload Message-ID: Hi, I am trying to upload a package to the Gilith OpenTheory repository using the opentheory tool. The upload fails with this error: Error: package arm-model-1.0 is already staged for installation I think the only reason it is already staged for installation is due to a failed attempt of mine previously to upload the package. Is there any way for me to cancel this attempt if I have lost the link the tool printed out initially? (My next question is going to be about why the initial failure occurred (there was no error message as far as I recall)...) Cheers, Ramana -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Fri May 13 17:19:03 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 13 May 2016 10:19:03 -0700 Subject: [opentheory-users] Retract upload In-Reply-To: References: Message-ID: Hi Ramana, You should have received an email asking you to confirm the upload. If you visit that link you can click on the other option, "Report to the repo maintainer that I am not the author" which should delete the upload. Cheers, Joe On Fri, May 13, 2016 at 1:45 AM, Ramana Kumar wrote: > Hi, > > I am trying to upload a package to the Gilith OpenTheory repository using > the opentheory tool. The upload fails with this error: > > Error: package arm-model-1.0 is already staged for installation > > I think the only reason it is already staged for installation is due to a > failed attempt of mine previously to upload the package. Is there any way > for me to cancel this attempt if I have lost the link the tool printed out > initially? > > (My next question is going to be about why the initial failure occurred > (there was no error message as far as I recall)...) > > Cheers, > Ramana > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From joe at gilith.com Fri May 13 18:22:13 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 13 May 2016 11:22:13 -0700 Subject: [opentheory-users] extending the standard library In-Reply-To: References: Message-ID: Hi Ramana, Thanks for taking the time to synchronize the discussion. > On creating theories in the HOL4 namespace, and depending on the hol-base > package: I see these as interim measures, with my desired goal being that > the > theorems and additional constants eventually all make it into the standard > namespace and depend on a nicely organised, unified, tree of packages. I > think > we probably agree on that goal, but I'm not sure. What do you say? Yes, I agree. I see the HOL4 namespace and the hol-base package as a convenient place to put HOL4-specific theories while we decide what will be the highest value to port to the "nicely organised, unified, tree of packages" depending only on the standard theory library. > More generally, my goal is to put together OpenTheory packages that are so > compelling in their organisation and coverage, having taken theorems from > all > the existing HOL provers, that everyone wants to use them. I want to move > towards unification and away from fragmentation. I would be sad if > OpenTheory > simply becomes a mirror of the existing fragmentation and incompatibility > between the various theorem prover libraries today. Do you agree with this > more > general goal? Agreed also, which is somewhat motivating my resistance to including totalized constants (see below). > I would like to discuss how to achieve the HOL4-specific goal now, because I > think we have enough information to make progress on such a discussion > (enough > HOL4 packages are already created). (This is in response to "When the HOL4 > theory packages are in place...".) OK sure, let's now discuss moving HOL4 packages away from their holding station in the HOL4 namespace depending on the hol-base package. > Now back to the questions from my previous email: > > - Do you agree with the three pieces of my solution to issue (2)? How do > you > think responsibility for those tasks should be divided between readers > and > creators? For issue (2) I was only considering the case where native and OpenTheory constants have different but isomorphic types, such as zip which might be defined as either of A list * B list -> (A * B) list A list -> B list -> (A * B) list If this is the only difference we can provide an unconditional equation between the OpenTheory and native variants of these constants. I agree with your three pieces of the solution, and I would hope that the theory creator could handle all of them so the reader would not have to know about the native constant with the different type. Actually, this is not strictly true, since reading such a theory might involve defining the HOL4 variant of the constant (just as reading the real theory involves defining some symbols in the HOLLight namespace), but I am ok with generating a bit of name pollution in logical kernels that are not purely functional. [This can already happen when auxiliary definitions are made to support definitions and proofs.] > - I guess your response "I'm loath to totalize any of the constants..." was > mainly to my suggested solution 0 to issue (3). That is a reasonable > objection to solution 0. > But: > What do you think of solution 1, namely, providing multiple versions of > constants that can be overspecified (in addition to the underspecified > version), together with theorems relating them? I've thought a lot about this, and am still not sure about adding totalized constants to OpenTheory theories that are intended to be read into arbitrary environments. For a concrete case, let's consider defining the HOL4 real inverse function: |- !x. inv0 x = if x = 0 then 0 else inv 0 This makes it clear that when the argument can be proved to be non-zero, then inv0 and inv are interchangeable. The problem is that if I add inv0 to the real theory, then it has no binding in an environment that doesn't contain that totalized constant. And similarly the theorems about inv0, such as |- inv0 0 = 0 don't have any equivalents in this environment. So we'd essentially be asking this environment to define inv0 and prove these theorems, because they'd be used in the proof of other theorems not involving inv0. In general each environment would have to define each variant of totalized constants, and maintain them as visible symbols with searchable theorems about them. The alternative I'd prefer would be for the native symbols to be hidden inside theories (HOL4.inv instead of inv0), just as in the case of native symbols with different types, which would require their properties to be proved each time inside theories that use them instead of being proved once and exported (static linking instead of dynamic linking). This focus on minimizing the work of the reader admittedly maximizes the burden on theory creators, but at least it avoids each environment needing to define and maintain properties of constant variants from other environments. In the extreme case of purely functional logical kernels then variants of constants from other environments just exist transiently to support proofs and are otherwise completely invisible. Cheers, Joe From ramana at member.fsf.org Fri May 13 23:33:04 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Sat, 14 May 2016 09:33:04 +1000 Subject: [opentheory-users] Retract upload In-Reply-To: References: Message-ID: I have tried all the links sent by email and they all say the upload has been confirmed or expired. I don't think any link was sent for the original failing upload which has left something in the staging area. On 14 May 2016 03:19, "Joe Leslie-Hurd" wrote: > Hi Ramana, > > You should have received an email asking you to confirm the upload. If > you visit that link you can click on the other option, > > "Report to the repo maintainer that I am not the author" > > which should delete the upload. > > Cheers, > > Joe > > On Fri, May 13, 2016 at 1:45 AM, Ramana Kumar > wrote: > > Hi, > > > > I am trying to upload a package to the Gilith OpenTheory repository using > > the opentheory tool. The upload fails with this error: > > > > Error: package arm-model-1.0 is already staged for installation > > > > I think the only reason it is already staged for installation is due to a > > failed attempt of mine previously to upload the package. Is there any way > > for me to cancel this attempt if I have lost the link the tool printed > out > > initially? > > > > (My next question is going to be about why the initial failure occurred > > (there was no error message as far as I recall)...) > > > > Cheers, > > Ramana > > > > > > _______________________________________________ > > 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 joe at gilith.com Mon May 16 04:54:17 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 15 May 2016 21:54:17 -0700 Subject: [opentheory-users] Print unsatisfied assumptions In-Reply-To: References: Message-ID: Hi Ramana, I've implemented this functionality, which is available in the latest released version and the github development snapshot. I simply changed the semantics of the --assumptions information to make it respect the --show-assumptions flag, so opentheory info --assumptions now only outputs the unsatisfied assumptions in article format, and the old behaviour is recovered by opentheory info --show-assumptions --assumptions which outputs all the assumptions of a theory. This mirrors the behaviour of opentheory info --theory. Hopefully this gives you what you need. Cheers, Joe On Mon, May 9, 2016 at 11:58 PM, Ramana Kumar wrote: > Abstractly, my use-case is: > I have a package A that develops some concepts that are already in a > standard library package, B. > A is developed from scratch, but goes much further than B. > I want to present A as if it were based on B, rather than developed from > scratch. > So, I pull out the foundations from A, replace them by B, and then I want to > see what remaining foundational assumptions need to be proved manually > (starting from what is provided by B). > > On 10 May 2016 at 16:08, Joe Leslie-Hurd wrote: >> >> I can't think of any way of persuading the existing opentheory tool to >> give you this functionality, except in the way you describe. >> >> I'd be happy to add the functionality to the tool, but it may take a >> little while. >> >> As a matter of curiosity, what is your use-case for this functionality? >> >> Cheers, >> >> Joe >> >> On Sun, May 8, 2016 at 7:09 PM, Ramana Kumar >> wrote: >> > Hi, >> > >> > How can I get the unsatisfied assumptions of a theory in article format? >> > >> > I know about the info --assumptions option, but it prints _all_ >> > assumptions, >> > including the satisfied ones. >> > >> > The only way I have found so far to do it is to create a fake package >> > that >> > imports all the required packages and print the assumptions of that. But >> > it's rather cumbersome to do so. Especially because importing the >> > required >> > packages also means figuring out all their dependencies and recreating >> > them >> > as blocks within the theory file in the right order. >> > >> > I know the opentheory tool knows how to calculate just the unsatisfied >> > assumptions. How can I get them out of it? >> > >> > Cheers, >> > Ramana >> > >> > >> > _______________________________________________ >> > 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 > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From joe at gilith.com Mon May 16 05:25:09 2016 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 15 May 2016 22:25:09 -0700 Subject: [opentheory-users] Retract upload In-Reply-To: References: Message-ID: Hi Ramana, Yes, you are quite correct. There were two packages in the staging area with no corresponding active uploads, which I was able to cleanup: $ opentheory cleanup cleaned up staged package arm-model-1.0 cleaned up staged package arm-step-1.0 I have no idea how it happened. Please retry the upload and let me know if something weird happens again. Cheers, Joe On Fri, May 13, 2016 at 4:33 PM, Ramana Kumar wrote: > I have tried all the links sent by email and they all say the upload has > been confirmed or expired. I don't think any link was sent for the original > failing upload which has left something in the staging area. > > On 14 May 2016 03:19, "Joe Leslie-Hurd" wrote: >> >> Hi Ramana, >> >> You should have received an email asking you to confirm the upload. If >> you visit that link you can click on the other option, >> >> "Report to the repo maintainer that I am not the author" >> >> which should delete the upload. >> >> Cheers, >> >> Joe >> >> On Fri, May 13, 2016 at 1:45 AM, Ramana Kumar >> wrote: >> > Hi, >> > >> > I am trying to upload a package to the Gilith OpenTheory repository >> > using >> > the opentheory tool. The upload fails with this error: >> > >> > Error: package arm-model-1.0 is already staged for installation >> > >> > I think the only reason it is already staged for installation is due to >> > a >> > failed attempt of mine previously to upload the package. Is there any >> > way >> > for me to cancel this attempt if I have lost the link the tool printed >> > out >> > initially? >> > >> > (My next question is going to be about why the initial failure occurred >> > (there was no error message as far as I recall)...) >> > >> > Cheers, >> > Ramana >> > >> > >> > _______________________________________________ >> > 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 > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From ramana at member.fsf.org Tue May 24 07:09:48 2016 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 24 May 2016 17:09:48 +1000 Subject: [opentheory-users] Print unsatisfied assumptions In-Reply-To: References: Message-ID: Joe, Thank you very much for implementing that. The design you chose looks very nice. I will try it out as soon as I get a chance (it may be a couple of weeks from now, though). Cheers, Ramana On 16 May 2016 at 14:54, Joe Leslie-Hurd wrote: > Hi Ramana, > > I've implemented this functionality, which is available in the latest > released version and the github development snapshot. > > I simply changed the semantics of the --assumptions information to > make it respect the --show-assumptions flag, so > > opentheory info --assumptions > > now only outputs the unsatisfied assumptions in article format, and > the old behaviour is recovered by > > opentheory info --show-assumptions --assumptions > > which outputs all the assumptions of a theory. This mirrors the > behaviour of opentheory info --theory. > > Hopefully this gives you what you need. > > Cheers, > > Joe > > On Mon, May 9, 2016 at 11:58 PM, Ramana Kumar > wrote: > > Abstractly, my use-case is: > > I have a package A that develops some concepts that are already in a > > standard library package, B. > > A is developed from scratch, but goes much further than B. > > I want to present A as if it were based on B, rather than developed from > > scratch. > > So, I pull out the foundations from A, replace them by B, and then I > want to > > see what remaining foundational assumptions need to be proved manually > > (starting from what is provided by B). > > > > On 10 May 2016 at 16:08, Joe Leslie-Hurd wrote: > >> > >> I can't think of any way of persuading the existing opentheory tool to > >> give you this functionality, except in the way you describe. > >> > >> I'd be happy to add the functionality to the tool, but it may take a > >> little while. > >> > >> As a matter of curiosity, what is your use-case for this functionality? > >> > >> Cheers, > >> > >> Joe > >> > >> On Sun, May 8, 2016 at 7:09 PM, Ramana Kumar > >> wrote: > >> > Hi, > >> > > >> > How can I get the unsatisfied assumptions of a theory in article > format? > >> > > >> > I know about the info --assumptions option, but it prints _all_ > >> > assumptions, > >> > including the satisfied ones. > >> > > >> > The only way I have found so far to do it is to create a fake package > >> > that > >> > imports all the required packages and print the assumptions of that. > But > >> > it's rather cumbersome to do so. Especially because importing the > >> > required > >> > packages also means figuring out all their dependencies and recreating > >> > them > >> > as blocks within the theory file in the right order. > >> > > >> > I know the opentheory tool knows how to calculate just the unsatisfied > >> > assumptions. How can I get them out of it? > >> > > >> > Cheers, > >> > Ramana > >> > > >> > > >> > _______________________________________________ > >> > 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 > > > > > > > > _______________________________________________ > > 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: