From rda at lemma-one.com Mon Mar 10 12:04:57 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 10 Mar 2014 12:04:57 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Joe, On 25 Feb 2014, at 22:14, Joe Leslie-Hurd wrote: > Hi Ramana, > > I'd never read that note by Rob, and it's very clear and persuasive. Although I have a natural resistance to changing the article file format in any way, the proposed primitive constant definition mechanism does seem to offer an improvement in expressivity at a modest cost of being more complicated to explain. If you are going to change the format, can I make two feature requests: 1) Even though you never, ever, ever want to change it again, allow for the possibility by adding a new command ?version? that pops a number off the stack. The number tells the virtual machine what version of the format the input file conforms to. In the absence of a ?version? command, the default is 5 (i.e., the version before the ?version? command was introduced). 2) Have a new command ?diag? that is identical with ?pop? as far as the virtual machine semantics is concerned but can be used in an implementation of the virtual machine to trigger some kind of diagnostic activity, like printing a report on the state of the virtual machine. I implemented ?diag? in the ProofPower reader and writer and I don?t believe I would have been able to get the writer working without it. It also gives a simple way of adding commentary to an article (you put the comment as a string followed by the diag command). Another reason for wanting it is that I think the article format has a potential use to do some useful application-specific things, e.g., I have clients who are interested in porting between a subset of Z in ProofPower and HOL4. ?diag" would be helpful to give some application-specific hints to the reader, e.g., to tell it the name to use when it saves a theorem, without preventing the articles being compatible with other systems. > > I would consider changing the OpenTheory logical kernel to support it, particularly if HOL4 or ProofPower incorporated it as the primitive constant definition mechanism, but I'd be interested to hear what John has to say about it. John, Ramana, Scott Owens and I talked about this a few months ago. There was general agreement to adopt the new constant definition mechanism once someone had confirmed my informal proof of correctness with a formal proof. Ramana has done that now. It is certainly only a matter of time before I implement it in ProofPower. It would be nice to be able to extend my OpenTheory reader/writer to handle it at the same time. Over to John and Ramana for the plans for HOL Light and ProofPower. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at xrchz.net Mon Mar 10 12:41:17 2014 From: ramana at xrchz.net (Ramana Kumar) Date: Mon, 10 Mar 2014 12:41:17 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: On Mon, Mar 10, 2014 at 12:04 PM, Rob Arthan wrote: > 1) Even though you never, ever, ever want to change it again, allow for > the possibility by adding a new command ?version? that pops a number off > the stack. The number tells the virtual machine what version of the format > the input file conforms to. In the absence of a ?version? command, the > default is 5 (i.e., the version before the ?version? command was > introduced). > I second this request! I believe Michael Norrish made a similar request earlier - oh, actually it was in a private email. > 2) Have a new command ?diag? that is identical with ?pop? as far as the > virtual machine semantics is concerned but can be used in an implementation > of the virtual machine to trigger some kind of diagnostic activity, like > printing a report on the state of the virtual machine. > > I implemented ?diag? in the ProofPower reader and writer and I don?t > believe I would have been able to get the writer working without it. It > also gives a simple way of adding commentary to an article (you put the > comment as a string followed by the diag command). Another reason for > wanting it is that I think the article format has a potential use to do > some useful application-specific things, e.g., I have clients who are > interested in porting between a subset of Z in ProofPower and HOL4. ?diag" > would be helpful to give some application-specific hints to the reader, > e.g., to tell it the name to use when it saves a theorem, without > preventing the articles being compatible with other systems. > I also agree this would be useful. This has been discussed before: http://www.gilith.com/opentheory/mailing-list/2011-October/000167.html. > I would consider changing the OpenTheory logical kernel to support it, > particularly if HOL4 or ProofPower incorporated it as the primitive > constant definition mechanism, but I'd be interested to hear what John has > to say about it. > > > John, Ramana, Scott Owens and I talked about this a few months ago. There > was general agreement to adopt the new constant definition mechanism once > someone had confirmed my informal proof of correctness with a formal proof. > Ramana has done that now. It is certainly only a matter of time before I > implement it in ProofPower. It would be nice to be able to extend my > OpenTheory reader/writer to handle it at the same time. > Well, I have proved something about it, but I'm not sure it is as strong as what your informal proof said (which was conservativity) ;) Nevertheless I expect to prove that soon. > Over to John and Ramana for the plans for HOL Light and ProofPower. > I have implemented the revised new_specification for HOL4 and plan to integrate it with the master development branch as soon as it is supported by OpenTheory. I don't want to do it before then because that would break HOL4's OpenTheory exporter (since I replaced new_definition with the new rule for specification, which has no OpenTheory analogue to export to as yet). > > Regards, > > Rob. > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Mon Mar 10 16:09:13 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 10 Mar 2014 16:09:13 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Ramana, On 10 Mar 2014, at 12:41, Ramana Kumar wrote: > On Mon, Mar 10, 2014 at 12:04 PM, Rob Arthan wrote: > 1) Even though you never, ever, ever want to change it again, allow for the possibility by adding a new command ?version? that pops a number off the stack. The number tells the virtual machine what version of the format the input file conforms to. In the absence of a ?version? command, the default is 5 (i.e., the version before the ?version? command was introduced). > > I second this request! I believe Michael Norrish made a similar request earlier - oh, actually it was in a private email. > > 2) Have a new command ?diag? that is identical with ?pop? as far as the virtual machine semantics is concerned but can be used in an implementation of the virtual machine to trigger some kind of diagnostic activity, like printing a report on the state of the virtual machine. > > I implemented ?diag? in the ProofPower reader and writer and I don?t believe I would have been able to get the writer working without it. It also gives a simple way of adding commentary to an article (you put the comment as a string followed by the diag command). Another reason for wanting it is that I think the article format has a potential use to do some useful application-specific things, e.g., I have clients who are interested in porting between a subset of Z in ProofPower and HOL4. ?diag" would be helpful to give some application-specific hints to the reader, e.g., to tell it the name to use when it saves a theorem, without preventing the articles being compatible with other systems. > > I also agree this would be useful. This has been discussed before: http://www.gilith.com/opentheory/mailing-list/2011-October/000167.html. Thanks for the pointer. I wasn?t reading this list very actively at that time. You were using ?pop" with a test for a special form of the stack to implement a diagnostic check. I think with my proposal you can implement that kind of thing and be sure that it won?t be fooled by ?pop?s that accidentally occur with the stack in the special form. I don?t see any particular need to standardise the semantics other than to say that ?diag? is equivalent to ?pop? as far as the virtual machine semantics are concerned. > >> I would consider changing the OpenTheory logical kernel to support it, particularly if HOL4 or ProofPower incorporated it as the primitive constant definition mechanism, but I'd be interested to hear what John has to say about it. > > John, Ramana, Scott Owens and I talked about this a few months ago. There was general agreement to adopt the new constant definition mechanism once someone had confirmed my informal proof of correctness with a formal proof. Ramana has done that now. It is certainly only a matter of time before I implement it in ProofPower. It would be nice to be able to extend my OpenTheory reader/writer to handle it at the same time. > > Well, I have proved something about it, but I'm not sure it is as strong as what your informal proof said (which was conservativity) ;) Nevertheless I expect to prove that soon. Great! Thanks for all your efforts on this. > > Over to John and Ramana for the plans for HOL Light and ProofPower. > > I have implemented the revised new_specification for HOL4 and plan to integrate it with the master development branch as soon as it is supported by OpenTheory. I don't want to do it before then because that would break HOL4's OpenTheory exporter (since I replaced new_definition with the new rule for specification, which has no OpenTheory analogue to export to as yet). > I am in much the same position: I could emulate the new rule with the existing OpenTheory defineConst and the choice operator, but it would be a tedious throw-away piece of work, if we are agreed that OpenTheory needs to support the new rule. I would propose leaving defineConst in OpenTheory as it is trivial to implement in terms of the new rule, so articles conforming to version 5 will still work. Out of interest, what have you called the new rule? Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Tue Mar 11 18:22:32 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 11 Mar 2014 18:22:32 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: On Mon, Mar 10, 2014 at 4:09 PM, Rob Arthan wrote: > Out of interest, what have you called the new rule? > I followed your lead in calling it "gen_new_specification". Initially I was using "loose_specification", which I think is worse. I think "gen_" is pretty good. Alternatively I might, in the end, go for a backwards incompatible change (for HOL4) and make the new rule "new_specification" and the old new_specification something else like "existential_specification". > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Tue Mar 11 20:25:55 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Tue, 11 Mar 2014 20:25:55 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: On Mon, Mar 10, 2014 at 4:09 PM, Rob Arthan wrote: > John, Ramana, Scott Owens and I talked about this a few months ago. There > was general agreement to adopt the new constant definition mechanism once > someone had confirmed my informal proof of correctness with a formal proof. > Ramana has done that now. It is certainly only a matter of time before I > implement it in ProofPower. It would be nice to be able to extend my > OpenTheory reader/writer to handle it at the same time. > > Well, I have proved something about it, but I'm not sure it is as strong > as what your informal proof said (which was conservativity) ;) Nevertheless > I expect to prove that soon. > > > Great! Thanks for all your efforts on this. > Further to this, I have just finished proving a semantic version of conservativity for the revised new_specification rule. That is: if you start in a context that has a model then update the context by making a new_specification, the resulting context still has a model. That's probably all I'll do. For the curious, the theorem can be found here: https://github.com/xrchz/vml/blob/master/hol-light/stateful/holSoundnessScript.sml#L391(although that link might not stay valid very long). -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus.myreen at cl.cam.ac.uk Tue Mar 11 20:36:16 2014 From: magnus.myreen at cl.cam.ac.uk (Magnus Myreen) Date: Wed, 12 Mar 2014 07:36:16 +1100 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: On 12 March 2014 07:25, Ramana Kumar wrote: > On Mon, Mar 10, 2014 at 4:09 PM, Rob Arthan wrote: >> >> John, Ramana, Scott Owens and I talked about this a few months ago. There >> was general agreement to adopt the new constant definition mechanism once >> someone had confirmed my informal proof of correctness with a formal proof. >> Ramana has done that now. It is certainly only a matter of time before I >> implement it in ProofPower. It would be nice to be able to extend my >> OpenTheory reader/writer to handle it at the same time. >> >> Well, I have proved something about it, but I'm not sure it is as strong >> as what your informal proof said (which was conservativity) ;) Nevertheless >> I expect to prove that soon. >> >> >> Great! Thanks for all your efforts on this. > > > Further to this, I have just finished proving a semantic version of > conservativity for the revised new_specification rule. That is: if you start > in a context that has a model then update the context by making a > new_specification, the resulting context still has a model. That's probably > all I'll do. For the curious, the theorem can be found here: > https://github.com/xrchz/vml/blob/master/hol-light/stateful/holSoundnessScript.sml#L391 > (although that link might not stay valid very long). This link might stay valid for longer: https://github.com/xrchz/vml/blob/d3f84400361838ad28423168c0ecb3f0569aa244/hol-light/stateful/holSoundnessScript.sml#L391 > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From joe at gilith.com Fri Mar 14 17:07:31 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 14 Mar 2014 10:07:31 -0700 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: I like the suggestions for changing the format, I'm making a new draft standard of the article format that I'll ask for feedback on shortly. However, for right now I have a question about the new constant definition mechanism. Since OpenTheory has a purely functional logical kernel and there's no mechanism for accessing theorems that are not exported from a theory, I'm not really motivated by arguments arguing against a definition mechanism that permits unintended identities (RJ1). Naturally I require soundness (RJ2), and I would very much like a mechanism based on equality alone (JH1, RA1), but the current constant definition principle gives me that. So for me the powerful argument for the new definition principle is the ability to define new constants that are currently undefinable due to a stronger than necessary condition on type variables (RA2). However, now I'm carefully reading the proposal, a couple of things occur to me: 1. The exact wording in RA2 is "The condition on type variables imposed by new specification is stronger than one would like." But what about new_definition? Does that also have a stronger-than-necessary condition on type variables? Can you define constants using the proposed mechanism that cannot be defined using new_definition? 2. Assuming a positive answer to (1), I wonder whether the proposed mechanism can be simplified to a single variable (i.e., providing the input theorem v = t |- P[v] defines a new constant c and returns the theorem |- P[c]). Given a theory of pairs (which can be built with new_definition), you could then build the general proposed mechanism on top of this by the following three steps: (i) Define c: v = (t_1,t_2,...,t_n) |- P[FST v, FST (SND v), ... SND (... (SND v))] (ii) Define the family of constants c_1, ..., c_n: v_1 = FST c |- v_1 = FST c v_2 = FST (SND c) |- v_2 = FST (SND c) ... v_n = SND (... (SND c)) |- v_n = SND (... (SND c)) (iii) Derive |- P[c_1, c_2, ..., c_n] Because OpenTheory has a purely functional kernel and you can only access theorems that are exported a theory, the client will have no access to the "internal" constant c and the theorems derived in (i) and (ii). I recognize there are arguments for the general proposed mechanism to be the primitive in the HOL theorem provers, but I'd very much like the simplest possible mechanism to be the primitive in OpenTheory, assuming it has the same expressive power. Cheers, Joe On Tue, Mar 11, 2014 at 1:36 PM, Magnus Myreen wrote: > On 12 March 2014 07:25, Ramana Kumar wrote: > > On Mon, Mar 10, 2014 at 4:09 PM, Rob Arthan wrote: > >> > >> John, Ramana, Scott Owens and I talked about this a few months ago. > There > >> was general agreement to adopt the new constant definition mechanism > once > >> someone had confirmed my informal proof of correctness with a formal > proof. > >> Ramana has done that now. It is certainly only a matter of time before I > >> implement it in ProofPower. It would be nice to be able to extend my > >> OpenTheory reader/writer to handle it at the same time. > >> > >> Well, I have proved something about it, but I'm not sure it is as strong > >> as what your informal proof said (which was conservativity) ;) > Nevertheless > >> I expect to prove that soon. > >> > >> > >> Great! Thanks for all your efforts on this. > > > > > > Further to this, I have just finished proving a semantic version of > > conservativity for the revised new_specification rule. That is: if you > start > > in a context that has a model then update the context by making a > > new_specification, the resulting context still has a model. That's > probably > > all I'll do. For the curious, the theorem can be found here: > > > https://github.com/xrchz/vml/blob/master/hol-light/stateful/holSoundnessScript.sml#L391 > > (although that link might not stay valid very long). > > This link might stay valid for longer: > > > https://github.com/xrchz/vml/blob/d3f84400361838ad28423168c0ecb3f0569aa244/hol-light/stateful/holSoundnessScript.sml#L391 > > > _______________________________________________ > > 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 Fri Mar 14 21:35:53 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 14 Mar 2014 14:35:53 -0700 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: I have thought about this some more, and I believe I have answered my own questions. 1. The proposed definition mechanism is not more expressive than new_definition, because it can be simulated by first defining c_1 = t_1, ..., c_n = t_n, instantiating the given theorem with the substitution [c_1/v_1, ..., c_n/v_n], and then using the definition theorems of the c_i to prove the hypotheses. So I think the best thing is to keep the OpenTheory defineConst mechanism, and "compile" the proposed definition mechanism using the above scheme. 2. I think my simplification is bogus because defining the c_i in terms of c can fail because of the type variable condition. I've created a draft standard article format at http://www.gilith.com/research/opentheory/article.html with the proposed new commands (native and version) highlighted. Please take a look and let me know what you think. Cheers, Joe On Fri, Mar 14, 2014 at 10:07 AM, Joe Leslie-Hurd wrote: > I like the suggestions for changing the format, I'm making a new draft > standard of the article format that I'll ask for feedback on shortly. > > However, for right now I have a question about the new constant definition > mechanism. Since OpenTheory has a purely functional logical kernel and > there's no mechanism for accessing theorems that are not exported from a > theory, I'm not really motivated by arguments arguing against a definition > mechanism that permits unintended identities (RJ1). Naturally I require > soundness (RJ2), and I would very much like a mechanism based on equality > alone (JH1, RA1), but the current constant definition principle gives me > that. > > So for me the powerful argument for the new definition principle is the > ability to define new constants that are currently undefinable due to a > stronger than necessary condition on type variables (RA2). However, now I'm > carefully reading the proposal, a couple of things occur to me: > > 1. The exact wording in RA2 is "The condition on type variables imposed by > new specification is > stronger than one would like." But what about new_definition? Does that > also have a stronger-than-necessary condition on type variables? Can you > define constants using the proposed mechanism that cannot be defined using > new_definition? > > 2. Assuming a positive answer to (1), I wonder whether the proposed > mechanism can be simplified to a single variable (i.e., providing the input > theorem v = t |- P[v] defines a new constant c and returns the theorem |- > P[c]). Given a theory of pairs (which can be built with new_definition), > you could then build the general proposed mechanism on top of this by the > following three steps: > > (i) Define c: v = (t_1,t_2,...,t_n) |- P[FST v, FST (SND v), ... SND (... > (SND v))] > > (ii) Define the family of constants c_1, ..., c_n: > > v_1 = FST c |- v_1 = FST c > v_2 = FST (SND c) |- v_2 = FST (SND c) > ... > v_n = SND (... (SND c)) |- v_n = SND (... (SND c)) > > (iii) Derive |- P[c_1, c_2, ..., c_n] > > Because OpenTheory has a purely functional kernel and you can only access > theorems that are exported a theory, the client will have no access to the > "internal" constant c and the theorems derived in (i) and (ii). > > I recognize there are arguments for the general proposed mechanism to be > the primitive in the HOL theorem provers, but I'd very much like the > simplest possible mechanism to be the primitive in OpenTheory, assuming it > has the same expressive power. > > Cheers, > > Joe > > > > On Tue, Mar 11, 2014 at 1:36 PM, Magnus Myreen > wrote: > >> On 12 March 2014 07:25, Ramana Kumar wrote: >> > On Mon, Mar 10, 2014 at 4:09 PM, Rob Arthan wrote: >> >> >> >> John, Ramana, Scott Owens and I talked about this a few months ago. >> There >> >> was general agreement to adopt the new constant definition mechanism >> once >> >> someone had confirmed my informal proof of correctness with a formal >> proof. >> >> Ramana has done that now. It is certainly only a matter of time before >> I >> >> implement it in ProofPower. It would be nice to be able to extend my >> >> OpenTheory reader/writer to handle it at the same time. >> >> >> >> Well, I have proved something about it, but I'm not sure it is as >> strong >> >> as what your informal proof said (which was conservativity) ;) >> Nevertheless >> >> I expect to prove that soon. >> >> >> >> >> >> Great! Thanks for all your efforts on this. >> > >> > >> > Further to this, I have just finished proving a semantic version of >> > conservativity for the revised new_specification rule. That is: if you >> start >> > in a context that has a model then update the context by making a >> > new_specification, the resulting context still has a model. That's >> probably >> > all I'll do. For the curious, the theorem can be found here: >> > >> https://github.com/xrchz/vml/blob/master/hol-light/stateful/holSoundnessScript.sml#L391 >> > (although that link might not stay valid very long). >> >> This link might stay valid for longer: >> >> >> https://github.com/xrchz/vml/blob/d3f84400361838ad28423168c0ecb3f0569aa244/hol-light/stateful/holSoundnessScript.sml#L391 >> >> > _______________________________________________ >> > 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 rda at lemma-one.com Sat Mar 15 12:36:38 2014 From: rda at lemma-one.com (Rob Arthan) Date: Sat, 15 Mar 2014 12:36:38 +0000 Subject: [opentheory-users] native In-Reply-To: References: Message-ID: Joe, I will reply to the points about new_specification separately. On 14 Mar 2014, at 21:35, Joe Leslie-Hurd wrote: > with the proposed new commands (native and version) highlighted. Please take a look and let me know what you think. I don?t much like the name ?native?, but I can see why you didn?t like ?diag?. How about ?pragma?? ?version? is fine. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Sat Mar 15 13:30:29 2014 From: rda at lemma-one.com (Rob Arthan) Date: Sat, 15 Mar 2014 13:30:29 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Joe, On 14 Mar 2014, at 21:35, Joe Leslie-Hurd wrote: > I have thought about this some more, and I believe I have answered my own questions. > > 1. The proposed definition mechanism is not more expressive than new_definition, because it can be simulated by first defining c_1 = t_1, ..., c_n = t_n, instantiating the given theorem with the substitution [c_1/v_1, ..., c_n/v_n], and then using the definition theorems of the c_i to prove the hypotheses. It doesn?t claim to be more expressive. What it is designed to offer is abstraction. The OpenTheory kernel has a different way of hiding representation details, but HOL4, HOL Light, ProofPower and the OpenTheory article format don?t have that option. > So I think the best thing is to keep the OpenTheory defineConst mechanism, and "compile" the proposed definition mechanism using the above scheme. > But that means that the article format can?t express the desired abstraction in a way that can be ported from one system to another. That seems like a major shortfall to me. My proposal for OpenTheory would be a new command, called ?spec? say, which would actually provide the functionality of new_type, new_const, new_axiom, new_specification, gen_new_specification and new_type_definition in their HOL4, ProofPower and HOL Light guises. (Here gen_new_specification is the new principle from HOL Constant Definition Done Right.) ?spec" would have four parameters: (1) a list of type name/arity pairs identifying new types to be introduced; (2) a list of constant name/type pairs identifying new constants to be introduced (the types in list (1) may appear in the types of these constants); (3) A list of sequents giving new axioms to be introduced (the types in list (1) and the constants in list (2) may appear in these sequence); (4) a list of objects, which constitute a ?justification? for the new axiom. (4) would be empty for new_axiom, new_const or new_type. It would give the input theorem for new_specification, gen_new_specification and new_type_definition. A reader would analyse the parameters to figure out the best way to introduce the types and constants and so derive the required axioms. Recognising the various new_XYZ forms that I listed above and allowing for the differences between systems is easy and the reader can always fall back on a combination of new_type, new_const and new_axiom (or some kind of cheat). By making parameter (4) a list of objects, the ?spec? command is general enough to accommodate any conceivable extension to the definitional mechanisms without changing the article format. The ?spec? also makes the article format support higher levels of abstraction. For example, it would let the Gilith OpenTheory repo describe the types and constants in the base package (and others) in a way that is easy to import. The pair type for example, would be introduced by a spec command that introduces the type constructor ?x", the constants ?,?, ?fst? and ?snd? and with the theorems that characterize the type in terms of these constants as the new axioms. The justification could be a string like ?primitive? to hint to a reader that it should already have the types and constants. This declarative approach would make the base package a really useful resource (solving the problems discussed in this thread: [opentheory-users] Importing from the Gilith OpenTheory Repo). > 2. I think my simplification is bogus because defining the c_i in terms of c can fail because of the type variable condition. > That is correct. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Mon Mar 17 06:34:40 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 16 Mar 2014 23:34:40 -0700 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Hi Rob, I thought about your comments, and I take your point that even though OpenTheory uses theory boundaries to enforce abstraction there are some compelling reasons to support a definition principle such as your new proposed mechanism that has better abstraction properties. One of the design goals of OpenTheory is to have very precisely defined standards, to maximize compatibility between tools that implement them, and even though I can see the conceptual unity of your proposed "spec" command it doesn't give precise enough instructions as to what the reader should do for my taste. Instead I have sketched out the spec for a draft "defineConstList" command http://www.gilith.com/research/opentheory/article.html#defineConstListCommand which is intended to match your proposed definition mechanism. Writers using this command will almost certainly need to save the new constants to the dictionary to build new terms, hence the need for another new command to take apart lists: http://www.gilith.com/research/opentheory/article.html#hdTlCommand which is simply the inverse of cons. I was reluctant before now to introduce any derived inference rules, because another design goal of OpenTheory is to make it as simple as possible to implement readers. However, I have convinced myself that this is not an issue, because you can convert a version 6 article into a logically equivalent version 5 article, and so a reader can always perform this preprocessing step to avoid dealing with derived rules. Following this new line of thinking, I have introduced some extra derived rules http://www.gilith.com/research/opentheory/article.html#symCommand http://www.gilith.com/research/opentheory/article.html#transCommand http://www.gilith.com/research/opentheory/article.html#proveHypCommand that only depend on equality, and if writers choose to make use of them will hopefully help to compress the resulting article files. Please take a look at the new version 6 draft standard and let me know what you think: http://www.gilith.com/research/opentheory/article.html Cheers, Joe On Sat, Mar 15, 2014 at 6:30 AM, Rob Arthan wrote: > Joe, > > On 14 Mar 2014, at 21:35, Joe Leslie-Hurd wrote: > > I have thought about this some more, and I believe I have answered my own > questions. > > 1. The proposed definition mechanism is not more expressive than > new_definition, because it can be simulated by first defining c_1 = t_1, > ..., c_n = t_n, instantiating the given theorem with the substitution > [c_1/v_1, ..., c_n/v_n], and then using the definition theorems of the c_i > to prove the hypotheses. > > > It doesn't claim to be more expressive. What it is designed to offer is > abstraction. The OpenTheory kernel has a different way of hiding > representation details, but HOL4, HOL Light, ProofPower and the OpenTheory > article format don't have that option. > > So I think the best thing is to keep the OpenTheory defineConst mechanism, > and "compile" the proposed definition mechanism using the above scheme. > > But that means that the article format can't express the desired > abstraction in a way that can be ported from one system to another. That > seems like a major shortfall to me. > > My proposal for OpenTheory would be a new command, called "spec" say, > which would actually provide the functionality of new_type, new_const, > new_axiom, new_specification, gen_new_specification and new_type_definition > in their HOL4, ProofPower and HOL Light guises. (Here gen_new_specification > is the new principle from HOL Constant Definition Done Right.) "spec" would > have four parameters: > > (1) a list of type name/arity pairs identifying new types to be introduced; > (2) a list of constant name/type pairs identifying new constants to be > introduced (the types in list (1) may appear in the types of these > constants); > (3) A list of sequents giving new axioms to be introduced (the types in > list (1) and the constants in list (2) may appear in these sequence); > (4) a list of objects, which constitute a "justification" for the new > axiom. > > (4) would be empty for new_axiom, new_const or new_type. It would give the > input theorem for new_specification, gen_new_specification and > new_type_definition. > > A reader would analyse the parameters to figure out the best way to > introduce the types and constants and so derive the required axioms. > Recognising the various new_XYZ forms that I listed above and allowing for > the differences between systems is easy and the reader can always fall back > on a combination of new_type, new_const and new_axiom (or some kind of > cheat). > > By making parameter (4) a list of objects, the "spec" command is general > enough to accommodate any conceivable extension to the definitional > mechanisms without changing the article format. > > The "spec" also makes the article format support higher levels of > abstraction. For example, it would let the Gilith OpenTheory repo describe > the types and constants in the base package (and others) in a way that is > easy to import. The pair type for example, would be introduced by a spec > command that introduces the type constructor "x", the constants ",", "fst" > and "snd" and with the theorems that characterize the type in terms of > these constants as the new axioms. The justification could be a string like > "primitive" to hint to a reader that it should already have the types and > constants. This declarative approach would make the base package a really > useful resource (solving the problems discussed in this thread: [opentheory-users] > Importing from the Gilith OpenTheory Repo > ). > > 2. I think my simplification is bogus because defining the c_i in terms of > c can fail because of the type variable condition. > > That is correct. > > Regards, > > Rob. > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Mon Mar 17 06:35:38 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 16 Mar 2014 23:35:38 -0700 Subject: [opentheory-users] native In-Reply-To: References: Message-ID: I like the suggestion of "pragma": http://www.gilith.com/research/opentheory/article.html#pragmaCommand Cheers, Joe On Sat, Mar 15, 2014 at 5:36 AM, Rob Arthan wrote: > Joe, > > I will reply to the points about new_specification separately. > > On 14 Mar 2014, at 21:35, Joe Leslie-Hurd wrote: > > with the proposed new commands (native and version) highlighted. Please > take a look and let me know what you think. > > > I don't much like the name "native", but I can see why you didn't like > "diag". How about "pragma"? > > "version" is fine. > > Regards, > > Rob. > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Mon Mar 17 12:37:04 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 17 Mar 2014 12:37:04 +0000 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Joe, Thanks for the quick response. On 17 Mar 2014, at 06:34, Joe Leslie-Hurd wrote: > Hi Rob, > > I thought about your comments, and I take your point that even though OpenTheory uses theory boundaries to enforce abstraction there are some compelling reasons to support a definition principle such as your new proposed mechanism that has better abstraction properties. > > One of the design goals of OpenTheory is to have very precisely defined standards, to maximize compatibility between tools that implement them, and even though I can see the conceptual unity of your proposed "spec" command it doesn't give precise enough instructions as to what the reader should do for my taste. I thought it was precise. The reader must introduce the new types and constants and make the sequence become axioms. The only implementation-defined aspect is that it can use the justification to do this theory extension conservatively if it knows how. However, ... > > Instead I have sketched out the spec for a draft "defineConstList" command > > http://www.gilith.com/research/opentheory/article.html#defineConstListCommand ? I can?t complain! The above is what I (and, I guess, Ramana) had in mind originally. However, that still leaves me with the problem of the other thread, which amounts to the fact that I do not see a practical way of implementing a reader that can make use of the Gilith OpenTheory Repo. I will expand on that in the other thread. > > which is intended to match your proposed definition mechanism. Writers using this command will almost certainly need to save the new constants to the dictionary to build new terms, hence the need for another new command to take apart lists: > > http://www.gilith.com/research/opentheory/article.html#hdTlCommand > > which is simply the inverse of cons. > > I was reluctant before now to introduce any derived inference rules, because another design goal of OpenTheory is to make it as simple as possible to implement readers. However, I have convinced myself that this is not an issue, because you can convert a version 6 article into a logically equivalent version 5 article, and so a reader can always perform this preprocessing step to avoid dealing with derived rules. > > Following this new line of thinking, I have introduced some extra derived rules > > http://www.gilith.com/research/opentheory/article.html#symCommand > http://www.gilith.com/research/opentheory/article.html#transCommand > http://www.gilith.com/research/opentheory/article.html#proveHypCommand > > that only depend on equality, and if writers choose to make use of them will hopefully help to compress the resulting article files. > > Please take a look at the new version 6 draft standard and let me know what you think: > > http://www.gilith.com/research/opentheory/article.html I am happy with the derived rules. By a fortunate coincidence, you have put the parameters to trans and proveHyp on the stack in the same order as I do in my writer. For proveHyp (and deductAntisym) it might be helpful to say explicitly that the rules do not fail if the formula phi is not present in Delta. Regards, Rob. > > Cheers, > > Joe > > > > On Sat, Mar 15, 2014 at 6:30 AM, Rob Arthan wrote: > Joe, > > On 14 Mar 2014, at 21:35, Joe Leslie-Hurd wrote: > >> I have thought about this some more, and I believe I have answered my own questions. >> >> 1. The proposed definition mechanism is not more expressive than new_definition, because it can be simulated by first defining c_1 = t_1, ..., c_n = t_n, instantiating the given theorem with the substitution [c_1/v_1, ..., c_n/v_n], and then using the definition theorems of the c_i to prove the hypotheses. > > It doesn?t claim to be more expressive. What it is designed to offer is abstraction. The OpenTheory kernel has a different way of hiding representation details, but HOL4, HOL Light, ProofPower and the OpenTheory article format don?t have that option. > >> So I think the best thing is to keep the OpenTheory defineConst mechanism, and "compile" the proposed definition mechanism using the above scheme. >> > But that means that the article format can?t express the desired abstraction in a way that can be ported from one system to another. That seems like a major shortfall to me. > > My proposal for OpenTheory would be a new command, called ?spec? say, which would actually provide the functionality of new_type, new_const, new_axiom, new_specification, gen_new_specification and new_type_definition in their HOL4, ProofPower and HOL Light guises. (Here gen_new_specification is the new principle from HOL Constant Definition Done Right.) ?spec" would have four parameters: > > (1) a list of type name/arity pairs identifying new types to be introduced; > (2) a list of constant name/type pairs identifying new constants to be introduced (the types in list (1) may appear in the types of these constants); > (3) A list of sequents giving new axioms to be introduced (the types in list (1) and the constants in list (2) may appear in these sequence); > (4) a list of objects, which constitute a ?justification? for the new axiom. > > (4) would be empty for new_axiom, new_const or new_type. It would give the input theorem for new_specification, gen_new_specification and new_type_definition. > > A reader would analyse the parameters to figure out the best way to introduce the types and constants and so derive the required axioms. Recognising the various new_XYZ forms that I listed above and allowing for the differences between systems is easy and the reader can always fall back on a combination of new_type, new_const and new_axiom (or some kind of cheat). > > By making parameter (4) a list of objects, the ?spec? command is general enough to accommodate any conceivable extension to the definitional mechanisms without changing the article format. > > The ?spec? also makes the article format support higher levels of abstraction. For example, it would let the Gilith OpenTheory repo describe the types and constants in the base package (and others) in a way that is easy to import. The pair type for example, would be introduced by a spec command that introduces the type constructor ?x", the constants ?,?, ?fst? and ?snd? and with the theorems that characterize the type in terms of these constants as the new axioms. The justification could be a string like ?primitive? to hint to a reader that it should already have the types and constants. This declarative approach would make the base package a really useful resource (solving the problems discussed in this thread: [opentheory-users] Importing from the Gilith OpenTheory Repo). > >> 2. I think my simplification is bogus because defining the c_i in terms of c can fail because of the type variable condition. >> > That is correct. > > Regards, > > Rob. > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Mon Mar 17 13:31:07 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 17 Mar 2014 13:31:07 +0000 Subject: [opentheory-users] update command Message-ID: <776F0B03-7E49-4277-9D3D-8E8B02536D1F@lemma-one.com> What does the open theory update command do? And what is the recommended way of bringing your copy of a repo up-to-date? Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Tue Mar 18 14:56:30 2014 From: rda at lemma-one.com (Rob Arthan) Date: Tue, 18 Mar 2014 14:56:30 +0000 Subject: [opentheory-users] Multiple definitions in base package Message-ID: I just installed the latest version of the base package and did: opentheory info ?article ?output base.art base The resulting article file contains multiple definitions of various constants in the HOLLight namespace. E.g., HOLLight.NUMSUM. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Tue Mar 18 17:49:19 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Mar 2014 10:49:19 -0700 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: References: Message-ID: Hi Rob, The HOLLight.* symbols are "auxiliary" type operators and constants that are used in proofs but not exported by any theory. So it's not unreasonable that it is defined multiple times in subtheories of base. However, what is surprising is that the article compression algorithm implemented in the opentheory tool does not fold the multiple definitions into a single definition. Thanks for the report: I'll look into the problem. This code will need reworking anyway to process the new article commands. If the multiple definitions are causing problems then as a workaround you can pick an arbitrary new name for any symbols in the HOLLight namespace, because such symbols are guaranteed never to be appear in any exported theorem. Cheers, Joe On Tue, Mar 18, 2014 at 7:56 AM, Rob Arthan wrote: > I just installed the latest version of the base package and did: > > opentheory info --article --output base.art base > > The resulting article file contains multiple definitions of various > constants in the HOLLight namespace. > E.g., HOLLight.NUMSUM. > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Tue Mar 18 18:25:53 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Mar 2014 11:25:53 -0700 Subject: [opentheory-users] new_specification In-Reply-To: References: Message-ID: Hi Rob, One of the design goals of OpenTheory is to have very precisely defined > standards, to maximize compatibility between tools that implement them, and > even though I can see the conceptual unity of your proposed "spec" command > it doesn't give precise enough instructions as to what the reader should do > for my taste. > > I thought it was precise. The reader must introduce the new types and > constants and make the sequence become axioms. The only > implementation-defined aspect is that it can use the justification to do > this theory extension conservatively if it knows how. However, ... > I think this point has become moot, but I wanted to add one thing: I can imagine article readers that are not connected to a theorem prover (e.g., a compiler reading a HOL definition of a program and then compiling it to native code). So I would really like the file format to be as brain-dead as possible, to encourage these applications. > Instead I have sketched out the spec for a draft "defineConstList" command > > > http://www.gilith.com/research/opentheory/article.html#defineConstListCommand > > > ... I can't complain! The above is what I (and, I guess, Ramana) had in mind > originally. However, that still leaves me with the problem of the other > thread, which amounts to the fact that I do not see a practical way of > implementing a reader that can make use of the Gilith OpenTheory Repo. I > will expand on that in the other thread. > I can see your point about integrating the base package into a theorem prover, and I confess I have not done enough eating of my own dogfood in this regard. It's been on my TODO list for a long time to take a fresh version of HOL Light and implement an OpenTheory reader so that a user can type something like import-theories ["base", "natural-prime"];; and it would read in these theories and give them a context where the exported symbols have been defined and the theorems have been proved, grafting as naturally as possible onto the existing HOL Light theories. Then whatever theorems the user proves can be exported with theory meta-data required: base required: natural-prime and the dependencies checked when the dependencies evolve. But I simply haven't got around to it... I am happy with the derived rules. By a fortunate coincidence, you have put > the parameters to trans and proveHyp on the stack in the same order as I do > in my writer. > Excellent. > For proveHyp (and deductAntisym) it might be helpful to say explicitly > that the rules do not fail if the formula phi is not present in Delta. > Thanks, that's a good suggestion. I've added the documentation to both commands. Cheers, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Tue Mar 18 18:32:52 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 18 Mar 2014 11:32:52 -0700 Subject: [opentheory-users] update command In-Reply-To: <776F0B03-7E49-4277-9D3D-8E8B02536D1F@lemma-one.com> References: <776F0B03-7E49-4277-9D3D-8E8B02536D1F@lemma-one.com> Message-ID: Hi Rob, The update command refreshes the local list of what theories are available on what repos, so you can see what theories are upgradable like so: $ opentheory list Upgradable natural-bits-1.9 Actually doing the upgrade is a bit fiddly: $ for thy in $(opentheory list --format NAME Upgradable) ; do opentheory install $thy ; done installed package natural-bits-1.25 I should just make a new upgrade command that packages this up nicely (c.f. other thread about long TODO list :-) Cheers, Joe On Mon, Mar 17, 2014 at 6:31 AM, Rob Arthan wrote: > What does the open theory update command do? And what is the recommended > way of bringing your copy of a repo up-to-date? > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Wed Mar 19 14:55:18 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 19 Mar 2014 14:55:18 +0000 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: References: Message-ID: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> Joe, On 18 Mar 2014, at 17:49, Joe Leslie-Hurd wrote: > Hi Rob, > > The HOLLight.* symbols are "auxiliary" type operators and constants that are used in proofs but not exported by any theory. So it's not unreasonable that it is defined multiple times in subtheories of base. However, what is surprising is that the article compression algorithm implemented in the opentheory tool does not fold the multiple definitions into a single definition. > > Thanks for the report: I'll look into the problem. This code will need reworking anyway to process the new article commands. > > If the multiple definitions are causing problems then as a workaround you can pick an arbitrary new name for any symbols in the HOLLight namespace, because such symbols are guaranteed never to be appear in any exported theorem. Thanks for that, it may come in useful. It will only work if the repeated definitions all give alpha-equivalent defining properties. I think the article format definition should specify whether redefinition is allowed (and I would vote strongly for a constraint forbidding redefinition). Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Wed Mar 19 15:16:57 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 19 Mar 2014 15:16:57 +0000 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> Message-ID: <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Joe, On 4 Dec 2013, at 17:53, Joe Leslie-Hurd wrote: > ... > 2. The constants and type operators listed as defined by a theory package only include those that appear in an exported theorem. The exact form of the definition of these symbols is internal to the package, and is something that users of the theory package should never need to know. In fact the OpenTheory logical kernel is purely functional, so auxiliary symbols such as the abs and rep functions don't even end up polluting a global symbol table (though this might theoretically cause problems in other HOL theorem provers that don't implement a purely functional logical kernel). > > 3. The base theory package is the standard theory library, which is supposed to be a common base implemented by all theorem provers in the HOL family, but of course not every theorem is proved in the same form in all HOL theorem provers, so there is a use case for importing the base theory package. > > Unfortunately there isn't a good way of generating a single article from base that can be imported by the HOL theorem provers, because the definitions will be mixed in with the theorems. > > However, you can use the opentheory tool to list all the 'leaf' theory packages inside base, using the following magic incantation: > > opentheory list --dependency-order '(Identity - IncludedBy) (Includes* base)' > > Suppose each theorem in the *-def theory packages can be replaced with a ProofPower theorem. The remaining theory packages in the list can be converted to an article using opentheory info --article and imported into ProofPower. These articles shouldn't make any definitions and their assumptions should only consist of theorems proved by theory packages earlier in the list. At the end of this process you would have every theorem in the base theory package imported into ProofPower. > > I hope that helps clear things up a bit. I am now trying to follow this procedure and am having one or two problems. The packages natural-numeral and natural-dest seem to be exceptions to the rule that all the definition live in packages with names of the form XYZ-def. The packages don?t seem to come out in dependency order. E.g., the first few leaf packages in the natural package come out like this: natural-add-def-1.18 natural-add-sub-def-1.3 natural-add-sub-thm-1.3 natural-add-thm-1.47 natural-def-1.23 But the definition of addition in natural-add-def depends on suc from natural-def. When you say ?the remaining theory packages in the list can be converted to an article using opentheory info ?article?, do you mean that I can create a single article for them all? If so how do I do it? (opentheory info seem only to support a single INPUT.) Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Mar 20 17:55:26 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 20 Mar 2014 10:55:26 -0700 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: Hi Rob, I am now trying to follow this procedure and am having one or two problems. > > The packages natural-numeral and natural-dest seem to be exceptions to the > rule that all the definition live in packages with names of the form > XYZ-def. > That's a bug, I will fix this in the standard theory library. The packages don't seem to come out in dependency order. E.g., the first > few leaf packages in the natural package come out like this: > > natural-add-def-1.18 > natural-add-sub-def-1.3 > natural-add-sub-thm-1.3 > natural-add-thm-1.47 > natural-def-1.23 > > But the definition of addition in natural-add-def depends on suc from > natural-def. > They seem to be in alphabetical order (the default), did you give the --dependency-order argument: opentheory list --dependency-order '(Identity - IncludedBy) (Includes* base) If so then there's a bug in your version of opentheory: it works on the latest version (opentheory 1.2 (release 20131211)). When you say "the remaining theory packages in the list can be converted to > an article using opentheory info --article", do you mean that I can create a > single article for them all? If so how do I do it? (opentheory info seem > only to support a single INPUT.) > There are a few options here: 1. In ProofPower read in all the leaf article files one by one. 2. Create a theory file thm.thy of the form bool-def { package: bool-def-1.10 } axiom-choice { package: axiom-choice-1.7 } axiom-extensionality { import: axiom-choice package: axiom-extensionality-1.8 } bool-int { import: axiom-choice import: axiom-extensionality package: bool-int-1.17 } ...repeat for each leaf theory... main { import: axiom-choice import: axiom-extensionality import: bool-int ... } and then run opentheory info --article -o thm.art thm.thy 3. Here's an ugly line of perl that does the whole thing in one go: opentheory list --dependency-order '(Identity - IncludedBy) (Includes* base)' | grep -v -- '-def-[0-9.]\+$' | perl -ne 'BEGIN { $b = "{\n"; } chomp; $_ =~ /^(.*)-[0-9.]+$/; print "$1 $b package: $_\n}\n\n"; $b .= " import: $1\n"; END { print "main $b}\n" }' | opentheory info --article -o thm.art theory:- Note this relies on being able to distinguish 'definition' leaf theories by the -def suffix, which as you point out is not the case in the current standard theory library, but that bug will soon be fixed. The above command takes about 45 seconds to complete on my machine and the resulting thm.art is 6Mb in size. Cheers, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Mar 20 17:58:00 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 20 Mar 2014 10:58:00 -0700 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: After sending this last email, I noticed that the bool-def theory block was accidentally included in the thm.thy file, please ignore that theory block. Cheers, Joe On Thu, Mar 20, 2014 at 10:55 AM, Joe Leslie-Hurd wrote: > Hi Rob, > > I am now trying to follow this procedure and am having one or two problems. >> >> The packages natural-numeral and natural-dest seem to be exceptions to >> the rule that all the definition live in packages with names of the form >> XYZ-def. >> > > That's a bug, I will fix this in the standard theory library. > > The packages don't seem to come out in dependency order. E.g., the first >> few leaf packages in the natural package come out like this: >> >> natural-add-def-1.18 >> natural-add-sub-def-1.3 >> natural-add-sub-thm-1.3 >> natural-add-thm-1.47 >> natural-def-1.23 >> >> But the definition of addition in natural-add-def depends on suc from >> natural-def. >> > > They seem to be in alphabetical order (the default), did you give the > --dependency-order argument: > > opentheory list --dependency-order '(Identity - IncludedBy) (Includes* > base) > > If so then there's a bug in your version of opentheory: it works on the > latest version (opentheory 1.2 (release 20131211)). > > When you say "the remaining theory packages in the list can be converted >> to an article using opentheory info --article", do you mean that I can >> create a single article for them all? If so how do I do it? (opentheory >> info seem only to support a single INPUT.) >> > > There are a few options here: > > 1. In ProofPower read in all the leaf article files one by one. > > 2. Create a theory file thm.thy of the form > > bool-def { > package: bool-def-1.10 > } > > axiom-choice { > package: axiom-choice-1.7 > } > > axiom-extensionality { > import: axiom-choice > package: axiom-extensionality-1.8 > } > > bool-int { > import: axiom-choice > import: axiom-extensionality > package: bool-int-1.17 > } > > ...repeat for each leaf theory... > > main { > import: axiom-choice > import: axiom-extensionality > import: bool-int > ... > } > > and then run > > opentheory info --article -o thm.art thm.thy > > 3. Here's an ugly line of perl that does the whole thing in one go: > > opentheory list --dependency-order '(Identity - IncludedBy) (Includes* > base)' | grep -v -- '-def-[0-9.]\+$' | perl -ne 'BEGIN { $b = "{\n"; } > chomp; $_ =~ /^(.*)-[0-9.]+$/; print "$1 $b package: $_\n}\n\n"; $b .= " > import: $1\n"; END { print "main $b}\n" }' | opentheory info --article -o > thm.art theory:- > > Note this relies on being able to distinguish 'definition' leaf theories > by the -def suffix, which as you point out is not the case in the current > standard theory library, but that bug will soon be fixed. > > The above command takes about 45 seconds to complete on my machine and the > resulting thm.art is 6Mb in size. > > Cheers, > > Joe > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Fri Mar 21 17:50:44 2014 From: rda at lemma-one.com (Rob Arthan) Date: Fri, 21 Mar 2014 17:50:44 +0000 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: On 20 Mar 2014, at 17:55, Joe Leslie-Hurd wrote: > Hi Rob, > > I am now trying to follow this procedure and am having one or two problems. > > The packages natural-numeral and natural-dest seem to be exceptions to the rule that all the definition live in packages with names of the form XYZ-def. > > That's a bug, I will fix this in the standard theory library. > > The packages don?t seem to come out in dependency order. E.g., the first few leaf packages in the natural package come out like this: > > natural-add-def-1.18 > natural-add-sub-def-1.3 > natural-add-sub-thm-1.3 > natural-add-thm-1.47 > natural-def-1.23 > > But the definition of addition in natural-add-def depends on suc from natural-def. > > They seem to be in alphabetical order (the default), did you give the --dependency-order argument: >> opentheory list --dependency-order '(Identity - IncludedBy) (Includes* base) > > If so then there's a bug in your version of opentheory: it works on the latest version (opentheory 1.2 (release 20131211)). It does work. I have no idea how I managed to foul up the command line (I transferred it from your e-mail to a terminal window with copy-and-paste!). > > When you say ?the remaining theory packages in the list can be converted to an article using opentheory info ?article?, do you mean that I can create a single article for them all? If so how do I do it? (opentheory info seem only to support a single INPUT.) > > There are a few options here: > > 1. In ProofPower read in all the leaf article files one by one. That is the solution I am currently working with. > > 2. Create a theory file thm.thy of the form > > bool-def { > package: bool-def-1.10 > } > > axiom-choice { > package: axiom-choice-1.7 > } > > axiom-extensionality { > import: axiom-choice > package: axiom-extensionality-1.8 > } > > bool-int { > import: axiom-choice > import: axiom-extensionality > package: bool-int-1.17 > } > > ...repeat for each leaf theory... > > main { > import: axiom-choice > import: axiom-extensionality > import: bool-int > ... > } > > and then run > > opentheory info --article -o thm.art thm.thy > > 3. Here's an ugly line of perl that does the whole thing in one go: > > opentheory list --dependency-order '(Identity - IncludedBy) (Includes* base)' | grep -v -- '-def-[0-9.]\+$' | perl -ne 'BEGIN { $b = "{\n"; } chomp; $_ =~ /^(.*)-[0-9.]+$/; print "$1 $b package: $_\n}\n\n"; $b .= " import: $1\n"; END { print "main $b}\n" }' | opentheory info --article -o thm.art theory:- > > Note this relies on being able to distinguish 'definition' leaf theories by the -def suffix, which as you point out is not the case in the current standard theory library, but that bug will soon be fixed. > > The above command takes about 45 seconds to complete on my machine and the resulting thm.art is 6Mb in size. This looks like it will be useful when you have sorted out the glitches in the package names. I have now imported the packages, bool, function, unit, pair, natural and option. The process is a bit clunky, but is perfectly workable. The Repo website is extremely helpful. So I would say my issues with designing a reader are resolved. One query: is the case constant in the option package really meant to be called Data.case.none.some? That doesn?t seem to agree with the web page for the package. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Mon Mar 24 05:07:13 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 23 Mar 2014 22:07:13 -0700 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: Hi Rob, The above command takes about 45 seconds to complete on my machine and the > resulting thm.art is 6Mb in size. > > > This looks like it will be useful when you have sorted out the glitches in > the package names. > Over the weekend I made a new release of the standard theory library http://opentheory.gilith.com/?pkg=base-1.158 so this command now works as intended to extract the "pure theorem" content. I have now imported the packages, bool, function, unit, pair, natural and > option. The process is a bit clunky, but is perfectly workable. The Repo > website is extremely helpful. So I would say my issues with designing a > reader are resolved. > Excellent, very glad to hear it. One query: is the case constant in the option package really meant to be > called Data.case.none.some? That doesn't seem to agree with the web page > for the package. > Case constants are treated specially by the opentheory printer, to support pretty-printing of case expressions. You can see some example case expressions in the parser theory: http://opentheory.gilith.com/opentheory/packages/parser-1.100/parser-1.100.html It's perhaps ugly, but to avoid the need for symbol tables the OpenTheory convention is to append the name of the constructors to the case constant, hence Data.Option.case.none.some. This makes it possible to pretty-print case.none.some x (\a. y a) z as case z of none -> x | some a -> y a You can see the true name and type of the case constant by hovering over it in the package document (the same goes for all variables and constants). Cheers, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Thu Mar 27 17:35:00 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 27 Mar 2014 17:35:00 +0000 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: Joe, On 24 Mar 2014, at 05:07, Joe Leslie-Hurd wrote: > Hi Rob, > >> The above command takes about 45 seconds to complete on my machine and the resulting thm.art is 6Mb in size. > > This looks like it will be useful when you have sorted out the glitches in the package names. In the mean time I carried on processing the leaf package articles one by one. I succeeded in getting the whole thing in with out any new axioms. Initially, because the only definition of something like Set.Fold I had to hand was quite a bit different from the one in the repo, I did a devious trick whereby I included the articles that define Set.Fold and Set.size, and then used the new pragma feature to arrange to run a script just after processing those articles that did the proofs that equate the imported Set.size to the native ProofPower size function. > > Over the weekend I made a new release of the standard theory library > > http://opentheory.gilith.com/?pkg=base-1.158 > > so this command now works as intended to extract the "pure theorem" content. Many thanks for that. I have now defined a set fold operation like the one in the repo and I can import the whole base package conservatively without any devious tricks in one go using the article file that your perl magic generates. I have just one outstanding concern: there are no theorems in the sum package and only one in the real package (and the only operators it uses are <= and sup. There don?t seem to be any uses of real or sum in the other packages in the repo, so I haven?t really been able to test that I have got the mappings right for these packages. Any suggestions would be welcome. I am trying with some success to load the other packages in the repo. In each case, I constructed an article for each package XYZ in the 35 package other than those included in the base package with the command: opentheory info ?article -o XYZ.art XYZ. The package modular seems to expect a constant called Number.Modular.modulus to be defined, but nothing defines it, so modular won?t load. The package word seems to expect a constant called ?Data.Word.width? but nothing defines it. byte will load, but the word10, word12 and word16 packages won?t, apparently because they are trying to redefine a constant called Number.Modular.equivalent. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Mar 27 18:04:42 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 27 Mar 2014 11:04:42 -0700 Subject: [opentheory-users] Importing from the Gilith OpenTheory Repo In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: Hi Rob, Many thanks for that. I have now defined a set fold operation like the one > in the repo and I can import the whole base package conservatively without > any devious tricks in one go using the article file that your perl magic > generates. > That is excellent news. I have just one outstanding concern: there are no theorems in the sum > package and only one in the real package (and the only operators it uses > are <= and sup. There don't seem to be any uses of real or sum in the other > packages in the repo, so I haven't really been able to test that I have got > the mappings right for these packages. Any suggestions would be welcome. > Hmm... do you have any suggestions for theorems about sum types that I could prove in a sum-thm package to help here? Does ProofPower contain any such theorems? I am trying with some success to load the other packages in the repo. In > each case, I constructed an article for each package XYZ in the 35 package > other than those included in the base package with the command: > > opentheory info --article -o XYZ.art XYZ. > That looks like a good thing to do, although you might also want to know the theories that XYZ depends on, either by looking at the requires: meta-data in XYZ.thy or by using the command opentheory info --requires XYZ This will tell you the intended load-order of theories. The package modular seems to expect a constant called > Number.Modular.modulus to be defined, but nothing defines it, so modular > won't load. The package word seems to expect a constant called > "Data.Word.width" but nothing defines it. byte will load, but the word10, > word12 and word16 packages won't, apparently because they are trying to > redefine a constant called Number.Modular.equivalent. > modular is an example of a parameterized theory, which expects its parameter symbols to be bound to symbols having the required properties. For each parameterized theory I have uploaded a witness theory that shows that these parameters can be satisfied, where the parameter symbols are defined in the witness theory. For example: $ opentheory install modular-witness installed package modular-witness-1.3 $ opentheory info --theory modular-witness 3 external type operators: -> bool natural 9 external constants: = ! /\ ==> ~ F T suc zero 8 satisfied assumptions: hidden 1 defined constant: modulus 1 theorem: |- ~(modulus = 0) The parameter symbols show up as defined symbols in the witness theory (i.e., the constant modulus), and the required properties show up as theorems (i.e., modulus is non-zero). word is another parameterized theory that instantiates modular, as can be seen in its theory source file: http://opentheory.gilith.com/opentheory/packages/word-def-1.64/word-def.thy The concrete word theories (e.g., byte, word16, etc) then instantiate the word theory with different word sizes, for example: http://opentheory.gilith.com/opentheory/packages/byte-def-1.73/byte-def.thy http://opentheory.gilith.com/opentheory/packages/word16-def-1.73/word16-def.thy The upshot is that you'll be able to read in these concrete theories just fine, but trying to read multiple of them will fail because they will define internal symbols carried over from modular and word (e.g., Number.Modular.equivalent) with the same name but different definitions. I'm not sure what to do about this, but let me continue this in the other thread about multiple definitions. Cheers, Joe -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Mar 27 18:21:09 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 27 Mar 2014 11:21:09 -0700 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> References: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> Message-ID: Hi Rob, I've given this some thought, because this redefinition problem can occur in a number of ways. As we have just seen on the other thread http://www.gilith.com/opentheory/mailing-list/2014-March/000373.html it is not constrained to a single article file, but also occurs when importing a sequence of articles that define symbols for "internal" use. What would you think of the following scheme, which involves a change to the article standard? Declare a particular name to be special (e.g., "" or "_") for definition commands, such that when a symbol of this name is defined a reader may substitute a fresh name instead. Then when articles are generated by the opentheory tool it can check which symbols appear in exported theories, and squash all the others to "". This would allow readers with global symbol tables to read articles with internal definitions with no problems. Thoughts? Cheers, Joe On Wed, Mar 19, 2014 at 7:55 AM, Rob Arthan wrote: > Joe, > > On 18 Mar 2014, at 17:49, Joe Leslie-Hurd wrote: > > Hi Rob, > > The HOLLight.* symbols are "auxiliary" type operators and constants that > are used in proofs but not exported by any theory. So it's not unreasonable > that it is defined multiple times in subtheories of base. However, what is > surprising is that the article compression algorithm implemented in the > opentheory tool does not fold the multiple definitions into a single > definition. > > Thanks for the report: I'll look into the problem. This code will need > reworking anyway to process the new article commands. > > If the multiple definitions are causing problems then as a workaround you > can pick an arbitrary new name for any symbols in the HOLLight namespace, > because such symbols are guaranteed never to be appear in any exported > theorem. > > > Thanks for that, it may come in useful. It will only work if the repeated > definitions all give alpha-equivalent defining properties. > > I think the article format definition should specify whether redefinition > is allowed (and I would vote strongly for a constraint forbidding > redefinition). > > Regards, > > Rob. > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Thu Mar 27 20:43:38 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 27 Mar 2014 20:43:38 +0000 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: References: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> Message-ID: Joe, On 27 Mar 2014, at 18:21, Joe Leslie-Hurd wrote: > Hi Rob, > > I've given this some thought, because this redefinition problem can occur in a number of ways. As we have just seen on the other thread > > http://www.gilith.com/opentheory/mailing-list/2014-March/000373.html > > it is not constrained to a single article file, but also occurs when importing a sequence of articles that define symbols for "internal" use. > > What would you think of the following scheme, which involves a change to the article standard? > > Declare a particular name to be special (e.g., "" or "_") for definition commands, such that when a symbol of this name is defined a reader may substitute a fresh name instead. Then when articles are generated by the opentheory tool it can check which symbols appear in exported theories, and squash all the others to "". This would allow readers with global symbol tables to read articles with internal definitions with no problems. First of all, a small technical point: when you contrast the functional kernel of the opentheory tool with the global symbol tables used by other tools, surely it is not the functional/imperative distinction that matters, but rather that other tools may not support local definitions in the theories managed by their global symbol tables. That said, I don?t see how your proposal could work unless the opentheory tool is guaranteeing that, if it defines objects with squashed names, then it will never refer to those objects. If there is more than one definition of a squashed name, the squashed name, ?_? (say), becomes overloaded and there is no way the reader can resolve the overloading. If the opentheory tool is going to guarantee not to refer to objects with squashed names, why does it bother to make the definitions at all? Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Mar 27 22:27:23 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 27 Mar 2014 15:27:23 -0700 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: References: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> Message-ID: Hi Rob, > > Declare a particular name to be special (e.g., "" or "_") for definition commands, such that when a symbol of this name is defined a reader may substitute a fresh name instead. Then when articles are generated by the opentheory tool it can check which symbols appear in exported theories, and squash all the others to "". This would allow readers with global symbol tables to read articles with internal definitions with no problems. > > First of all, a small technical point: when you contrast the functional kernel of the opentheory tool with the global symbol tables used by other tools, surely it is not the functional/imperative distinction that matters, but rather that other tools may not support local definitions in the theories managed by their global symbol tables. That's true, the OpenTheory standard library does rely on theorem provers being able to make local definitions that only feature in the proofs of a theory, not the exported theorems. In principle, since the principles of definition are conservative, local definitions could be removed from any article, but possibly at a cost of making it bigger. The proposal above is a way to ensure that the local definitions in any article do not exhibit any instances of multiple symbols having the same name. This does not present a problem for a purely functional kernel, but hopefully will help theorem provers that record definitions by name in a symbol table. > That said, I don't see how your proposal could work unless the opentheory tool is guaranteeing that, if it defines objects with squashed names, then it will never refer to those objects. If there is more than one definition of a squashed name, the squashed name, "_" (say), becomes overloaded and there is no way the reader can resolve the overloading. If the opentheory tool is going to guarantee not to refer to objects with squashed names, why does it bother to make the definitions at all? The latter scenario is what happens in practice: let me explain. After an article reads a defineConst command, the stack looks like: Thm ( |- c = t ) :: Const c :: rest-of-stack Typically, the next thing that happens is that the theorem and constant are popped off the stack and saved in a dictionary. When a term needs to be built using constant c, it is simply looked up in the dictionary: the article doesn't (and indeed can't) look it up by name. So for internal symbols, their name is really unimportant, and can be replaced with any fresh name. In the purely functional OpenTheory kernel, I won't need to change anything to deal with squashed names, they can simply all be called "" (and be distinguished by their definition). In a reader that maintains a symbol table, these internal symbols can be given any fresh name to allow them to be recorded in the symbol table with no clashes. This is why I was confused when you wrote this before: > > If the multiple definitions are causing problems then as a workaround you can pick an arbitrary new name for any symbols in the HOLLight namespace, because such symbols are guaranteed never to be appear in any exported theorem. > > Thanks for that, it may come in useful. It will only work if the repeated definitions all give alpha-equivalent defining properties. Hopefully the above explains why you can pick new fresh names for every definition, you don't have to pick the same name for each (possibly different) definition of "HOLLight.NUMSUM". So, do you think the proposed change will help with reading theories into ProofPower? Cheers, Joe From rda at lemma-one.com Sun Mar 30 13:01:51 2014 From: rda at lemma-one.com (Rob Arthan) Date: Sun, 30 Mar 2014 14:01:51 +0100 Subject: [opentheory-users] Multiple definitions in base package In-Reply-To: References: <15AE4B59-3513-4715-B5FA-304C4C3703DC@lemma-one.com> Message-ID: Joe, On 27 Mar 2014, at 22:27, Joe Leslie-Hurd wrote: > Hi Rob, > >>> Declare a particular name to be special (e.g., "" or "_") for definition commands, such that when a symbol of this name is defined a reader may substitute a fresh name instead. Then when articles are generated by the opentheory tool it can check which symbols appear in exported theories, and squash all the others to "". This would allow readers with global symbol tables to read articles with internal definitions with no problems. >> > ? > Typically, the next thing that happens is that the theorem and > constant are popped off the stack and saved in a dictionary. When a > term needs to be built using constant c, it is simply looked up in the > dictionary: the article doesn't (and indeed can't) look it up by name. > So for internal symbols, their name is really unimportant, and can be > replaced with any fresh name. ? > So, do you think the proposed change will help with reading theories > into ProofPower? Thanks for explaining how this is supposed to work. I am not sure I fully understand why the opentheory tool has to have abstraction mechanisms (local definitions) that aren?t supported by other HOL implementations. However, if you feel it is necessary to have a notion of local definitions, then I would suggest we be more explicit about it. I think the article spec should say that there is a local namespace: names beginning ?Local.? (say) belong to the local namespace. Once a name in the local namespace has been introduced as a quoted string, all subsequent references to the name are via a dictionary access. Thus the local namespace supports overloading, the dictionary being used to resolve the overloading. A reader may make an arbitrary choice of how to map a local name when it encounters one, providing it avoids clashes with names in other namespaces. To help trace what is going on, rather than replacing the name you got from HOL Light or whatever by ?? or ?_?, I suggest you prefix the original name with ?Local.?. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Mon Mar 31 13:26:20 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 31 Mar 2014 14:26:20 +0100 Subject: [opentheory-users] Type variable names In-Reply-To: <7ACC39A2-E21C-4B6E-A98E-743CCE0B86BC@lemma-one.com> References: <3ECF799F-BDD8-4B6D-A1AF-62F7064ABB78@lemma-one.com> <7ACC39A2-E21C-4B6E-A98E-743CCE0B86BC@lemma-one.com> Message-ID: <4BD97FF1-9296-4568-875E-D99EB6E318E0@lemma-one.com> On 19 Feb 2014, at 11:25, Rob Arthan wrote: > Joe, > > On 18 Feb 2014, at 18:22, Joe Leslie-Hurd wrote: > >> and for other theorem provers to rename on import and export between OpenTheory standard names and native names (just like what already happens with constant and type operator names). >> >> So applying the policy to your loopy scenario, I'm afraid it is the ProofPower importer and exporter that is in violation, and I suggest you implement Ramana's HOL4 procedure for importing and exporting type variable names. Then HOL4 and ProofPower should be able to play nicely with each other, and as a bonus with HOL Light too. > And I replied: > Well. I will see what it takes to amend Ramana's mapping so that it is guaranteed to be one-to-one. > Note that HOL4, HOL Light and ProofPower all allow mk_vartype to be called with an arbitrary string. So to handle pathological cases, we can?t make any assumptions about the strings. At first I thought we would need an input-dependent mapping, but I think the following fixed mapping works. ProofPower to OpenTheory: Case 1: type variable name comprises a prime followed by 1 or more alphanumerics or underscores: remove the prime and switch case of alphabetic characters. E.g. ??a? maps to ?A?, ??1_aZ? maps to ?1_Az?. Case 2: type variable name comprises 1 or more alphanumerics or underscores: prefix with a prime and switch case of alphabetic characters. E.g., ?Xyz? maps to ??xYZ?. Case 3: anything else: switch case of alphabetic characters.. E.g. ??? maps to ???. ?A b? maps to ?a B?. OpenTheory to ProofPower: Case 1: type variable name comprises 1 or more alphanumerics or underscores: prefix with a prime and switch case of alphabetic characters. E.g., ?Z? maps to ??z?, ?1_aZ? maps to ?1_zA?. Case 2: type variable name comprises a prime followed by 1 or more alphanumerics or underscores: remove the prime and switch case of alphabetic characters. E.g., ?'Xyz? maps to ?xYZ?. Case 3: anything else: switch case of alphabetic characters.. E.g. ??? maps to ???. ?A b? maps to ?a B?. I wasn?t certain about the pros and cons of switching case in cases 2 and 3, but it seemed more consistent always to switch case. Any comments welcome. Maybe Ramana might like to consider switching to the same scheme in the HOL4 OpenTheory implementation. (Apart from the fact that HOL4 warns that some type variable names are non-standard, I think it?s syntax rules and the conventions most users adopt agree with ProofPower.) Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Mon Mar 31 16:01:26 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 31 Mar 2014 17:01:26 +0100 Subject: [opentheory-users] Theorems about sums In-Reply-To: References: <97AF3AA1-8D33-4FE0-A48B-25E738011F98@lemma-one.com> <922736A7-5A86-446B-AB93-B227CD3A71BD@lemma-one.com> <2ADA0CEF-81C1-4926-B9FC-B22BD66213D5@lemma-one.com> <1D730FC1-7F8B-49D2-BCFC-C31EBD8ECA16@lemma-one.com> Message-ID: Joe, On 27 Mar 2014, at 18:04, Joe Leslie-Hurd wrote: > Hi Rob, > > Many thanks for that. I have now defined a set fold operation like the one in the repo and I can import the whole base package conservatively without any devious tricks in one go using the article file that your perl magic generates. > > That is excellent news. > > I have just one outstanding concern: there are no theorems in the sum package and only one in the real package (and the only operators it uses are <= and sup. There don?t seem to be any uses of real or sum in the other packages in the repo, so I haven?t really been able to test that I have got the mappings right for these packages. Any suggestions would be welcome. > > Hmm... do you have any suggestions for theorems about sum types that I could prove in a sum-thm package to help here? Does ProofPower contain any such theorems? > I didn?t have any to hand. The following are analogous to some of the theorems you have about pairs. ? ? p? (? x? p x) ? (? a? p (InL a)) ? (? b? p (InR b)) ? ? p? (? a? p a) ? (? x? p (OutL x)) ? ? p? (? b? p b) ? (? x? p (OutR x)) I can send you an article that proves these if you like (but the proofs are so easy, it is probably more trouble than it is worth). I will have a think about how you might populate real-thm. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: