From joe at gilith.com Wed Nov 5 22:49:17 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 14:49:17 -0800 Subject: [opentheory-users] New principle of constant definition Message-ID: Hi Rob, [I'm cc'ing the OpenTheory list because the discussion may be of general interest.] I just finished implementing the new principle of constant definition described in your paper "HOL Constant Definition Done Right": http://www.lemma-one.com/papers/hcddr.pdf It all makes perfect sense to me and the instructions were straightforward to follow, but I was wondering if you could explain the rationale behind this constraint: "the free variables of p must be contained in the v_i" It seems sound to permit extra free variables, for example in the following definition v = 0 |- n + v = n Also, why "contained in" and not "exactly"? If there are extra variables v_i that are not free in p, then it is a simple matter to remove them from the hypotheses before calling gen_new_specification. Finally, a practical point that I ran into during implementation: in the case where the set v_i is empty (i.e., there is nothing to define), should the input theorem simply be returned or do you consider that an error condition? Cheers, Joe From rda at lemma-one.com Wed Nov 5 23:21:57 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 5 Nov 2014 23:21:57 +0000 Subject: [opentheory-users] New principle of constant definition In-Reply-To: References: Message-ID: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> Joe, On 5 Nov 2014, at 22:49, Joe Leslie-Hurd wrote: > Hi Rob, > > [I'm cc'ing the OpenTheory list because the discussion may be of > general interest.] > > I just finished implementing the new principle of constant definition > described in your paper "HOL Constant Definition Done Right": > > http://www.lemma-one.com/papers/hcddr.pdf Excellent! > > It all makes perfect sense to me and the instructions were > straightforward to follow, but I was wondering if you could explain > the rationale behind this constraint: > > "the free variables of p must be contained in the v_i" > > It seems sound to permit extra free variables, for example in the > following definition > > v = 0 |- n + v = n It would be sound to permit that, but I have a prejudice against free variables in defining properties, so I was deliberately requiring the user to take the universal closure w.r.t. the variable n in an example like the above, so that the resulting defining property would be a closed formula. > > Also, why "contained in" and not "exactly"? If there are extra > variables v_i that are not free in p, then it is a simple matter to > remove them from the hypotheses before calling gen_new_specification. Yes, but then the rule won?t introduce the corresponding constants. I don?t think this is very important, but I didn?t want to require the user to impose a constraint on all the new constants. > > Finally, a practical point that I ran into during implementation: in > the case where the set v_i is empty (i.e., there is nothing to > define), should the input theorem simply be returned or do you > consider that an error condition? The current ProofPower implementation allows the set to be empty and just stores the input theorem as a definition (of nothing) in that case. I think that is it how it is specified in the CakeML work too. Maybe Ramana could confirm that. Regards, Rob. From joe at gilith.com Thu Nov 6 06:22:08 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 22:22:08 -0800 Subject: [opentheory-users] Release of opentheory tool supporting version 6 articles Message-ID: I'm happy to announce that the latest release of the opentheory tool, which is opentheory 1.3 (release 20141105) and is available for download at http://www.gilith.com/software/opentheory/download.html now supports version 6 of the article file format as described in http://www.gilith.com/research/opentheory/article.html The tool supports a new --output-version parameter to select the version of articles that it outputs (the default is version 6), so it's easy to convert between article versions like so: opentheory info --article -o foo5.art --output-version 5 foo.art opentheory info --article -o foo6.art --output-version 6 foo.art I have also modified my OpenTheory fork of HOL Light to emit version 6 articles, including an implementation of new_specification in terms of the defineConstList command, and have used it to produce a new version of the standard theory library. Here is the inference rule count for base-1.159, the latest publicly released version which uses version 5 articles: $ opentheory info --inference --article -o base5.art --output-version 5 base-1.159 Inference rules: eqMp ..................... 96,008 subst .................... 78,087 appThm ................... 68,967 refl ..................... 28,548 deductAntisym ............ 28,334 betaConv ................. 13,357 absThm ................... 12,953 assume .................... 4,181 axiom ..................... 3,185 defineConst ................. 219 defineTypeOp (legacy) ........ 13 Total ................... 333,852 And here's the count for base-1.165, which uses version 6 articles: $ opentheory info --inference --article -o base6.art --output-version 6 base-1.165 Inference rules: subst .............. 71,795 eqMp ............... 60,651 appThm ............. 40,755 proveHyp ........... 17,131 betaConv ........... 16,423 absThm ............. 12,532 trans .............. 12,254 refl ............... 10,665 deductAntisym ....... 7,955 sym ................. 7,669 assume .............. 4,222 axiom ............... 3,165 defineConst ........... 159 defineConstList ........ 60 defineTypeOp ........... 13 Total ............. 265,449 As can be seen, adding a handful of derived rules of inference results in a saving of both inference rule count and also article file size: $ gzip base5.art base6.art && gzip -l base5.art.gz base6.art.gz compressed uncompressed ratio uncompressed_name 1482155 9421490 84.2% base5.art 1125697 7508364 85.0% base6.art Please have a play with the new release of the opentheory tool and let me know if you see any issues. I'm especially interested in checking that it correctly implements the new principle of definition embodied by the defineConstList command, and I don't have a collection of interesting examples to try it on. In particular, following the recipe in Rob's paper for implementing new_specification means that each use of defineConstList in the standard theory library defines a single constant. Cheers, Joe From joe at gilith.com Thu Nov 6 06:31:03 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 22:31:03 -0800 Subject: [opentheory-users] Finalizing version 6 of the article file format standard Message-ID: Now that there is a release of the opentheory tool for processing version 6 articles, and I am sitting on a release of the standard theory library that uses version 6 articles, I'd like to finalize version 6 of the article file format standard, which is currently in draft mode: http://www.gilith.com/research/opentheory/article.html The commands that are new in version 6 are highlighted in yellow and the command with changed semantics (defineTypeOp) is highlighted in red. We have discussed the changes on this list, so there shouldn't be any surprises in store. Actually, there is one minor change that hasn't been discussed before. During implementation work on defineTypeOp I discovered that one of Mario's proposed theorems ? p = (\r. rep (abs r) = r) (1) required the axiom of extensionality to be logically equivalent to the same theorem produced by version 5 of defineTypeOp: ? p r = (rep (abs r) = r) (2) Although it would be theoretically possible to invoke the axiom of extensionality to convert between the two versions of defineTypeOp, I thought it was more elegant to reformulate theorem (1) by eta-expanding p: ? (\r. rep (abs r) = r) = \r. p r (3) [I also flipped the LHS and RHS so that theorem (3) has a pleasing similarity to the other theorem produced by defineTypeOp.] Now theorem (3) is logically equivalent to theorem (2) without requiring the axiom of extensionality, and retains the desirable property of having no free term variables. Anyway, there are no other "brown bag updates" to the standard, and I'd like to finalize it so we can start using it for real work. Does anybody have any objections or last-minute additions? Cheers, Joe From di.gama at gmail.com Thu Nov 6 06:45:58 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 6 Nov 2014 01:45:58 -0500 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: Message-ID: I was aware that equation (1) is stronger than (2) without extensionality, but I'm curious why this is a problem, since it is an axiom of the system and doesn't require proof. Any v5 proof that starts with (2) can easily be rebuilt to use (1), while conversely for a v6 proof there are very few theorems that follow from (1) but not (2) in the absence of extensionality (mostly trivial restatements of (1) itself), and I expect that any proof that starts from (1) will immediately wrap it with appThm, upon which point it will again be equivalent to (2). Mario On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: > Now that there is a release of the opentheory tool for processing > version 6 articles, and I am sitting on a release of the standard > theory library that uses version 6 articles, I'd like to finalize > version 6 of the article file format standard, which is currently in > draft mode: > > http://www.gilith.com/research/opentheory/article.html > > The commands that are new in version 6 are highlighted in yellow and > the command with changed semantics (defineTypeOp) is highlighted in > red. We have discussed the changes on this list, so there shouldn't be > any surprises in store. > > Actually, there is one minor change that hasn't been discussed before. > During implementation work on defineTypeOp I discovered that one of > Mario's proposed theorems > > ? p = (\r. rep (abs r) = r) (1) > > required the axiom of extensionality to be logically equivalent to the > same theorem produced by version 5 of defineTypeOp: > > ? p r = (rep (abs r) = r) (2) > > Although it would be theoretically possible to invoke the axiom of > extensionality to convert between the two versions of defineTypeOp, I > thought it was more elegant to reformulate theorem (1) > by eta-expanding p: > > ? (\r. rep (abs r) = r) = \r. p r (3) > > [I also flipped the LHS and RHS so that theorem (3) has a pleasing > similarity to the other theorem produced by defineTypeOp.] Now theorem > (3) is logically equivalent to theorem (2) without requiring the axiom > of extensionality, and retains the desirable property of having no > free term variables. > > Anyway, there are no other "brown bag updates" to the standard, and > I'd like to finalize it so we can start using it for real work. > > Does anybody have any objections or last-minute additions? > > 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 di.gama at gmail.com Thu Nov 6 06:50:56 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 6 Nov 2014 01:50:56 -0500 Subject: [opentheory-users] New principle of constant definition In-Reply-To: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> References: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> Message-ID: Could someone clue me in on why defineConstList (a.k.a gen_new_specification) is necessary? From the paper, I read that it takes as input v1 = t1, ..., vn = tn |- p and produces |- p[c1/v1, ..., cn/vn] Doesn't this trivially follow from the separate definitions c1 = t1, ..., cn = tn? What is the purpose of a separate redundant axiom for this? Mario On Wed, Nov 5, 2014 at 6:21 PM, Rob Arthan wrote: > Joe, > > On 5 Nov 2014, at 22:49, Joe Leslie-Hurd wrote: > > > Hi Rob, > > > > [I'm cc'ing the OpenTheory list because the discussion may be of > > general interest.] > > > > I just finished implementing the new principle of constant definition > > described in your paper "HOL Constant Definition Done Right": > > > > http://www.lemma-one.com/papers/hcddr.pdf > > Excellent! > > > > > It all makes perfect sense to me and the instructions were > > straightforward to follow, but I was wondering if you could explain > > the rationale behind this constraint: > > > > "the free variables of p must be contained in the v_i" > > > > It seems sound to permit extra free variables, for example in the > > following definition > > > > v = 0 |- n + v = n > > It would be sound to permit that, but I have a prejudice against > free variables in defining properties, so I was deliberately requiring > the user to take the universal closure w.r.t. the variable n in an > example like the above, so that the resulting defining property > would be a closed formula. > > > > > Also, why "contained in" and not "exactly"? If there are extra > > variables v_i that are not free in p, then it is a simple matter to > > remove them from the hypotheses before calling gen_new_specification. > > Yes, but then the rule won?t introduce the corresponding constants. > I don?t think this is very important, but I didn?t want to require > the user to impose a constraint on all the new constants. > > > > > Finally, a practical point that I ran into during implementation: in > > the case where the set v_i is empty (i.e., there is nothing to > > define), should the input theorem simply be returned or do you > > consider that an error condition? > > The current ProofPower implementation allows the set to be empty > and just stores the input theorem as a definition (of nothing) in that > case. I think that is it how it is specified in the CakeML work too. > Maybe Ramana could confirm that. > > 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 Thu Nov 6 06:51:37 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 22:51:37 -0800 Subject: [opentheory-users] New principle of constant definition In-Reply-To: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> References: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> Message-ID: Hi Rob, > It would be sound to permit that, but I have a prejudice against > free variables in defining properties, so I was deliberately requiring > the user to take the universal closure w.r.t. the variable n in an > example like the above, so that the resulting defining property > would be a closed formula. The aesthetic argument convinces me: I just wanted to check the condition wasn't also necessary for soundness in some subtle way. >> Also, why "contained in" and not "exactly"? If there are extra >> variables v_i that are not free in p, then it is a simple matter to >> remove them from the hypotheses before calling gen_new_specification. > > Yes, but then the rule won't introduce the corresponding constants. > I don't think this is very important, but I didn't want to require > the user to impose a constraint on all the new constants. >From the perspective of a purely functional logical kernel introducing a new constant with no defining property is a no-op, but in a traditional logical kernel with a symbol table I can see there might be a reason to introduce a new constant with a null definition. >> Finally, a practical point that I ran into during implementation: in >> the case where the set v_i is empty (i.e., there is nothing to >> define), should the input theorem simply be returned or do you >> consider that an error condition? > > The current ProofPower implementation allows the set to be empty > and just stores the input theorem as a definition (of nothing) in that > case. I think that is it how it is specified in the CakeML work too. > Maybe Ramana could confirm that. OK, I'll mirror this behavior in the opentheory tool. In this trivial case the rule should succeed iff the input theorem has no free variables. Cheers, Joe From joe at gilith.com Thu Nov 6 06:58:05 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 22:58:05 -0800 Subject: [opentheory-users] New principle of constant definition In-Reply-To: References: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> Message-ID: Hi Mario, Quoting from Rob Arthan when I asked the same question some months ago: "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." The latest release of the opentheory tool does indeed compile instances of defineConstList to defineConst exactly as you describe, if you feed it a version 6 article and ask for a version 5 article as output: opentheory info --article -o foo5.art --output-version 5 foo6.art Cheers, Joe On Wed, Nov 5, 2014 at 10:50 PM, Mario Carneiro wrote: > Could someone clue me in on why defineConstList (a.k.a > gen_new_specification) is necessary? From the paper, I read that it takes as > input > > v1 = t1, ..., vn = tn |- p > > and produces > > |- p[c1/v1, ..., cn/vn] > > Doesn't this trivially follow from the separate definitions c1 = t1, ..., cn > = tn? What is the purpose of a separate redundant axiom for this? > > Mario > > On Wed, Nov 5, 2014 at 6:21 PM, Rob Arthan wrote: >> >> Joe, >> >> On 5 Nov 2014, at 22:49, Joe Leslie-Hurd wrote: >> >> > Hi Rob, >> > >> > [I'm cc'ing the OpenTheory list because the discussion may be of >> > general interest.] >> > >> > I just finished implementing the new principle of constant definition >> > described in your paper "HOL Constant Definition Done Right": >> > >> > http://www.lemma-one.com/papers/hcddr.pdf >> >> Excellent! >> >> > >> > It all makes perfect sense to me and the instructions were >> > straightforward to follow, but I was wondering if you could explain >> > the rationale behind this constraint: >> > >> > "the free variables of p must be contained in the v_i" >> > >> > It seems sound to permit extra free variables, for example in the >> > following definition >> > >> > v = 0 |- n + v = n >> >> It would be sound to permit that, but I have a prejudice against >> free variables in defining properties, so I was deliberately requiring >> the user to take the universal closure w.r.t. the variable n in an >> example like the above, so that the resulting defining property >> would be a closed formula. >> >> > >> > Also, why "contained in" and not "exactly"? If there are extra >> > variables v_i that are not free in p, then it is a simple matter to >> > remove them from the hypotheses before calling gen_new_specification. >> >> Yes, but then the rule won't introduce the corresponding constants. >> I don't think this is very important, but I didn't want to require >> the user to impose a constraint on all the new constants. >> >> > >> > Finally, a practical point that I ran into during implementation: in >> > the case where the set v_i is empty (i.e., there is nothing to >> > define), should the input theorem simply be returned or do you >> > consider that an error condition? >> >> The current ProofPower implementation allows the set to be empty >> and just stores the input theorem as a definition (of nothing) in that >> case. I think that is it how it is specified in the CakeML work too. >> Maybe Ramana could confirm that. >> >> 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 > From joe at gilith.com Thu Nov 6 07:16:16 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 5 Nov 2014 23:16:16 -0800 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: Message-ID: Hi Mario, As you say, extensionality is an axiom of the system, but the use of it is explicitly tracked. For example, you can see which theorems in bool theory depend on it using the following command: opentheory info --theory --show-assumptions --show-derivations bool If defineTypeOp produced this: ? p = (\r. rep (abs r) = r) (1) then you could apply appThm, betaConv and absThm to get: ? (\r. p r) = (\r. rep (abs r) = r) (2) and then sym and trans using (1) and (2) to get ? (\r. p r) = p (3) which is an untracked application of extensionality for any non-empty predicate p. It seemed more elegant to reformulate the theorem to avoid this possibility. Cheers, Joe On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: > I was aware that equation (1) is stronger than (2) without extensionality, > but I'm curious why this is a problem, since it is an axiom of the system > and doesn't require proof. Any v5 proof that starts with (2) can easily be > rebuilt to use (1), while conversely for a v6 proof there are very few > theorems that follow from (1) but not (2) in the absence of extensionality > (mostly trivial restatements of (1) itself), and I expect that any proof > that starts from (1) will immediately wrap it with appThm, upon which point > it will again be equivalent to (2). > > Mario > > On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: >> >> Now that there is a release of the opentheory tool for processing >> version 6 articles, and I am sitting on a release of the standard >> theory library that uses version 6 articles, I'd like to finalize >> version 6 of the article file format standard, which is currently in >> draft mode: >> >> http://www.gilith.com/research/opentheory/article.html >> >> The commands that are new in version 6 are highlighted in yellow and >> the command with changed semantics (defineTypeOp) is highlighted in >> red. We have discussed the changes on this list, so there shouldn't be >> any surprises in store. >> >> Actually, there is one minor change that hasn't been discussed before. >> During implementation work on defineTypeOp I discovered that one of >> Mario's proposed theorems >> >> ? p = (\r. rep (abs r) = r) (1) >> >> required the axiom of extensionality to be logically equivalent to the >> same theorem produced by version 5 of defineTypeOp: >> >> ? p r = (rep (abs r) = r) (2) >> >> Although it would be theoretically possible to invoke the axiom of >> extensionality to convert between the two versions of defineTypeOp, I >> thought it was more elegant to reformulate theorem (1) >> by eta-expanding p: >> >> ? (\r. rep (abs r) = r) = \r. p r (3) >> >> [I also flipped the LHS and RHS so that theorem (3) has a pleasing >> similarity to the other theorem produced by defineTypeOp.] Now theorem >> (3) is logically equivalent to theorem (2) without requiring the axiom >> of extensionality, and retains the desirable property of having no >> free term variables. >> >> Anyway, there are no other "brown bag updates" to the standard, and >> I'd like to finalize it so we can start using it for real work. >> >> Does anybody have any objections or last-minute additions? >> >> Cheers, >> >> Joe >> >> _______________________________________________ >> 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 di.gama at gmail.com Thu Nov 6 07:23:14 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 6 Nov 2014 02:23:14 -0500 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: Message-ID: Oh wow, that's a pretty direct derivation of extensionality from my version of defineTypeOp. I stand corrected; certainly it's not desirable to have a "conservative extension" allow the derivation of an axiom before its introduction. And I guess that the next best thing if you want to maintain conservativity is exactly your version of the axiom. Mario On Thu, Nov 6, 2014 at 2:16 AM, Joe Leslie-Hurd wrote: > Hi Mario, > > As you say, extensionality is an axiom of the system, but the use of > it is explicitly tracked. For example, you can see which theorems in > bool theory depend on it using the following command: > > opentheory info --theory --show-assumptions --show-derivations bool > > If defineTypeOp produced this: > > ? p = (\r. rep (abs r) = r) (1) > > then you could apply appThm, betaConv and absThm to get: > > ? (\r. p r) = (\r. rep (abs r) = r) (2) > > and then sym and trans using (1) and (2) to get > > ? (\r. p r) = p (3) > > which is an untracked application of extensionality for any non-empty > predicate p. It seemed more elegant to reformulate the theorem to > avoid this possibility. > > Cheers, > > Joe > > On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: > > I was aware that equation (1) is stronger than (2) without > extensionality, > > but I'm curious why this is a problem, since it is an axiom of the system > > and doesn't require proof. Any v5 proof that starts with (2) can easily > be > > rebuilt to use (1), while conversely for a v6 proof there are very few > > theorems that follow from (1) but not (2) in the absence of > extensionality > > (mostly trivial restatements of (1) itself), and I expect that any proof > > that starts from (1) will immediately wrap it with appThm, upon which > point > > it will again be equivalent to (2). > > > > Mario > > > > On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: > >> > >> Now that there is a release of the opentheory tool for processing > >> version 6 articles, and I am sitting on a release of the standard > >> theory library that uses version 6 articles, I'd like to finalize > >> version 6 of the article file format standard, which is currently in > >> draft mode: > >> > >> http://www.gilith.com/research/opentheory/article.html > >> > >> The commands that are new in version 6 are highlighted in yellow and > >> the command with changed semantics (defineTypeOp) is highlighted in > >> red. We have discussed the changes on this list, so there shouldn't be > >> any surprises in store. > >> > >> Actually, there is one minor change that hasn't been discussed before. > >> During implementation work on defineTypeOp I discovered that one of > >> Mario's proposed theorems > >> > >> ? p = (\r. rep (abs r) = r) (1) > >> > >> required the axiom of extensionality to be logically equivalent to the > >> same theorem produced by version 5 of defineTypeOp: > >> > >> ? p r = (rep (abs r) = r) (2) > >> > >> Although it would be theoretically possible to invoke the axiom of > >> extensionality to convert between the two versions of defineTypeOp, I > >> thought it was more elegant to reformulate theorem (1) > >> by eta-expanding p: > >> > >> ? (\r. rep (abs r) = r) = \r. p r (3) > >> > >> [I also flipped the LHS and RHS so that theorem (3) has a pleasing > >> similarity to the other theorem produced by defineTypeOp.] Now theorem > >> (3) is logically equivalent to theorem (2) without requiring the axiom > >> of extensionality, and retains the desirable property of having no > >> free term variables. > >> > >> Anyway, there are no other "brown bag updates" to the standard, and > >> I'd like to finalize it so we can start using it for real work. > >> > >> Does anybody have any objections or last-minute additions? > >> > >> Cheers, > >> > >> Joe > >> > >> _______________________________________________ > >> 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 Fri Nov 7 17:25:09 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Fri, 7 Nov 2014 17:25:09 +0000 Subject: [opentheory-users] New principle of constant definition In-Reply-To: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> References: <6728081A-F7A0-448D-9768-DFFA56667CC5@lemma-one.com> Message-ID: On Wed, Nov 5, 2014 at 11:21 PM, Rob Arthan wrote: > The current ProofPower implementation allows the set to be empty > and just stores the input theorem as a definition (of nothing) in that > case. I think that is it how it is specified in the CakeML work too. > Maybe Ramana could confirm that. > Yes. [In the terminology of that work, the input theorem will become a new (though clearly conservative) axiom in the theory.] -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Fri Nov 7 21:45:09 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Fri, 7 Nov 2014 13:45:09 -0800 Subject: [opentheory-users] Theorem meta-data Message-ID: I've been doing some thinking about theorem names, which is a requested feature of articles and up to now I've been resisting, preferring to keep articles clean of meta-data and unnecessary names. However, in applications such as exporting theory packages as Haskell I can see value in assigning meta-data to theorems, and so I'd like to define a general scheme for it. Here are some constraints: 1. It should be semantically transparent, having no effect at all on logical dependencies between theories. 2. It should be maintained by tools processing articles (when possible). Note that pragmas are discarded by the opentheory tool, so fail this test for encoding meta-data. 3. It should be a standard scheme, not reader-dependent, so pragmas also fail for this reason. 4. At the theory level merging articles is a common operation, so there should be a standard way to merge meta-data having the idempotence property that (merge D D = D). I propose the thm article command take an additional metadata argument, where metadata is represented by the following datatype in ML syntax: datatype metadata = Metadata of (name, metadata) finite_map; This can be easily represented using article lists, so for example the metadata name: head_def HOLLight: name: HD simplifier would be represented as [["name",[["head_def",[]]]], ["HOLLight",[["name",[["HD",[]]],["simplifier",[]]]]] Merging two pieces of metadata would simply be the union of two finite maps, where if they map the same name then the inner finite maps are merged recursively. This has the desired idempotence property. There's still time to add this to version 6 of the article standard, if it was deemed a good idea. Any comments? Cheers, Joe From di.gama at gmail.com Sat Nov 8 02:01:23 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Fri, 7 Nov 2014 21:01:23 -0500 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: Message-ID: I think it will be more backwards-compatible to use a pragma instead, since this is already used by various interpreters. Regarding the arguments against pragmas: > 2. It should be maintained by tools processing articles (when > possible). Note that pragmas are discarded by the opentheory tool, so > fail this test for encoding meta-data. > This is easily fixed by making the opentheory tool not discard pragmas (or at least specific pragmas, see below). > 3. It should be a standard scheme, not reader-dependent, so pragmas > also fail for this reason. > The way to work a pragma into the standard is to reserve certain pragma names within the standard itself. For example, the current standard suggests the pragma ["thmName", name] for setting a theorem's name - in a revision to the standard, just require that this specific pragma be honored when possible, and leave the rest (any pragma not of this form) to be user-defined. For the current purpose, a pragma ["metadata", meta] would satisfy the desired conditions. The main drawbacks are that it is more verbose and also does not directly connect itself to the associated theorem, but it gains the ability to mark other statements, like intermediate theorems. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sat Nov 8 09:12:51 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 8 Nov 2014 01:12:51 -0800 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: Message-ID: Hi Mario, Thanks for your feedback on the proposal. I have given a lot of thought to your email, and in reply let me explain a little about my vision for the OpenTheory project. Firstly, I see the goal of the project as evolving a set of standards for proofs and theories to capture the needs of people wanting to exchange theories between theorem prover implementations. So I'm not too worried about maintaining backward compatibility if there's a measurable improvement, just like the situation with removing the unnecessary free variables from the theorems produced by defineTypeOp. Rob's suggestion of a version command makes incompatible changes in articles easy to deal with, and I will commit to ensuring that the opentheory tool will support all released versions of OpenTheory standards. My hope is that people developing tools will always choose the latest version of the standards, and not have to worry about processing earlier versions (perhaps using the opentheory tool to upgrade earlier versions if necessary). So in the context of an evolving set of standards I see the pragma article command as a laboratory for testing out new ideas in different article readers, with the idea that once new features are tested they can be standardized as new commands that every reader must implement in the same way. For example, if most readers support a debug pragma then I see no problem with creating a debug command in future versions of the article standard that all readers must respect. In this role of a test laboratory that different readers process in different ways, it seems that the opentheory tool has no choice but to discard pragma commands when producing articles. In the light of the above, and the requests I have heard to include theorem metadata in articles, I still see it as a good idea to propose an extra argument to the thm article command that all readers must process in the same way. I'd be interested in hearing your thoughts (and the thoughts of others on the list) on whether the specific proposal captures specific theorem metadata needs, or indeed whether there is enough added value to justify making a change at all. Cheers, Joe On Fri, Nov 7, 2014 at 6:01 PM, Mario Carneiro wrote: > I think it will be more backwards-compatible to use a pragma instead, since > this is already used by various interpreters. Regarding the arguments > against pragmas: > >> >> 2. It should be maintained by tools processing articles (when >> possible). Note that pragmas are discarded by the opentheory tool, so >> fail this test for encoding meta-data. > > > This is easily fixed by making the opentheory tool not discard pragmas (or > at least specific pragmas, see below). > >> >> 3. It should be a standard scheme, not reader-dependent, so pragmas >> also fail for this reason. > > > The way to work a pragma into the standard is to reserve certain pragma > names within the standard itself. For example, the current standard suggests > the pragma ["thmName", name] for setting a theorem's name - in a revision to > the standard, just require that this specific pragma be honored when > possible, and leave the rest (any pragma not of this form) to be > user-defined. > > For the current purpose, a pragma ["metadata", meta] would satisfy the > desired conditions. The main drawbacks are that it is more verbose and also > does not directly connect itself to the associated theorem, but it gains the > ability to mark other statements, like intermediate theorems. > > Mario > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From rda at lemma-one.com Sat Nov 8 12:53:04 2014 From: rda at lemma-one.com (Rob Arthan) Date: Sat, 8 Nov 2014 12:53:04 +0000 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: Message-ID: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Joe, On 8 Nov 2014, at 09:12, Joe Leslie-Hurd wrote: > Hi Mario, > > Thanks for your feedback on the proposal. I have given a lot of > thought to your email, and in reply let me explain a little about my > vision for the OpenTheory project. > > Firstly, I see the goal of the project as evolving a set of standards > for proofs and theories to capture the needs of people wanting to > exchange theories between theorem prover implementations. So I'm not > too worried about maintaining backward compatibility if there's a > measurable improvement, just like the situation with removing the > unnecessary free variables from the theorems produced by defineTypeOp. > > Rob's suggestion of a version command makes incompatible changes in > articles easy to deal with, and I will commit to ensuring that the > opentheory tool will support all released versions of OpenTheory > standards. My hope is that people developing tools will always choose > the latest version of the standards, and not have to worry about > processing earlier versions (perhaps using the opentheory tool to > upgrade earlier versions if necessary). I am looking forward to seeing how this works out when I finish upgrading my reader/writer for ProofPower to version 6. Will it be possible to do the conversion with the opentheory tool as a filter (so a script to import an article can just convert it to its preferred version on the fly)? > > So in the context of an evolving set of standards I see the pragma > article command as a laboratory for testing out new ideas in different > article readers, with the idea that once new features are tested they > can be standardized as new commands that every reader must implement > in the same way. For example, if most readers support a debug pragma > then I see no problem with creating a debug command in future versions > of the article standard that all readers must respect. In this role of > a test laboratory that different readers process in different ways, it > seems that the opentheory tool has no choice but to discard pragma > commands when producing articles. > > In the light of the above, and the requests I have heard to include > theorem metadata in articles, I still see it as a good idea to propose > an extra argument to the thm article command that all readers must > process in the same way. I'd be interested in hearing your thoughts > (and the thoughts of others on the list) on whether the specific > proposal captures specific theorem metadata needs, or indeed whether > there is enough added value to justify making a change at all. > I agree with the idea that readers must implement each command in the same way, but I take this as being relative to the representation chosen for the OpenTheory virtual machine in a particular reader. If you are going to say that the extra argument to the thm command must be processed in the same way, then you are going to have to extend the OpenTheory virtual machine to include the theorem metadata, so that you can define that processing. Were you planning to do that? If you weren?t planning to change the virtual machine, then this seems to me like a good candidate for a standardised pragma as Mario suggests. First that means there is no implementation overhead for anyone maintaining a reader and who doesn?t want to use the metadata. Secondly, the opentheory tool could duck the question of how to combine multiple metadata: it could just include all the relevant pragmas. Finally it seems intuitively right. since readers that do use the metadata are likely to use it in different ways, so it is a pragmatic matter, aside from the core semantics of OpenTheory. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Nov 9 00:24:39 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 8 Nov 2014 16:24:39 -0800 Subject: [opentheory-users] Theorem meta-data In-Reply-To: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: Hi Rob, > I am looking forward to seeing how this works out when I finish > upgrading my reader/writer for ProofPower to version 6. Will > it be possible to do the conversion with the opentheory tool > as a filter (so a script to import an article can just convert it > to its preferred version on the fly)? Indeed, this is already supported. This command reads an article (of any version) from stdin and writes an equivalent article on stdout using version 6: opentheory info --article --output-version 6 article:- > If you are going to say that the extra argument to the thm command > must be processed in the same way, then you are going to have > to extend the OpenTheory virtual machine to include the theorem > metadata, so that you can define that processing. Were you planning > to do that? No, I wasn't: my intention was that the theorem meta-data would be interpreted in a reader-dependent way. The proposal was merely a standard format for representing meta-data as finite maps represented by nested lists of names, not processing it. > If you weren't planning to change the virtual machine, then > this seems to me like a good candidate for a standardised > pragma as Mario suggests. It would certainly be possible to specify theorem meta-data using pragmas, and perhaps this is after all the best way to do it. However, in the spirit of yesterday's unsolicited philosophy lecture, I would like to take a stand against "standardized pragmas". Once a particular pragma has demonstrated its usefulness, my favoured approach would be to define a new command in the next version of the article spec standardizing its behaviour, rather than adding it to a set of standardized pragmas. This is what I meant when I said I saw pragmas as an experimental laboratory for new commands. Given this approach, there is no standardized behaviour for pragmas, and so the opentheory tool does not have the information to maintain them in articles it processes. Consider maintaining a "debug" pragma during processing that compresses an article by merging equivalent objects, or maintaining a "thmName" pragma during processing that reorders the exported theorems. My theorem meta-data proposal was an attempt to standardize the behaviour of thmName as a new command (i.e., the existing thm command with an extra argument) so that the opentheory tool could maintain the information during processing, but this discussion is persuading me that the benefit of the change may not be worth its cost. Cheers, Joe From di.gama at gmail.com Sun Nov 9 01:25:07 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sat, 8 Nov 2014 20:25:07 -0500 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: I think I'm starting to see the philosophical distinction that Rob is trying to make. The main body of commands in the current spec all change the state of the OT virtual machine in some way, with the only exception being the "pragma" command, which by contrast is required *not* to change anything which is tracked by the virtual machine. That is, you are not allowed to define a pragma that puts something on the stack, because then the machine wouldn't operate correctly if you took the command out or used a reader that didn't respect that pragma. The idea is simply to make this division remain true in later versions of the standard. Thus, "debug" can never be made an official command, because unless standard out is made a part of the virtual machine, it will always be a no-op with respect to the state variables which *are* in the virtual machine specification. Similarly, "thmName" can only be made an official command if the exported theorem list in the virtual machine state contains name information. In this case, it seems that the best way to incorporate "metadata" the way you are trying to do would involve a new type annotated_thm, which contains a thm object and a map of name -> object entries. The virtual machine assumption list would still be a list of thm, but the theorem list would be a list of annotated_thm, and your two-argument "thm" command would package the theorem and metadata together and appendthe resulting annotated_thm object to the theorem list. This way, it becomes mandatory to respect the metadata of a theorem in order to have correct semantics, so by the above-mentioned philosophy it would have to be an "official" command and not a pragma. Under the current model of the virtual machine, any metadata would have to be tracked outside the machine itself, which falls under the behavior of a pragma. One more remark: this is not a concern for article readers, but what should an article merger do if the theorem is mentioned with the same metadata key and different values? Your merging algorithm only works if the metadata is for different keys or is the same in both theorem objects. Mario On Sat, Nov 8, 2014 at 7:24 PM, Joe Leslie-Hurd wrote: > Hi Rob, > > > I am looking forward to seeing how this works out when I finish > > upgrading my reader/writer for ProofPower to version 6. Will > > it be possible to do the conversion with the opentheory tool > > as a filter (so a script to import an article can just convert it > > to its preferred version on the fly)? > > Indeed, this is already supported. This command reads an article (of > any version) from stdin and writes an equivalent article on stdout > using version 6: > > opentheory info --article --output-version 6 article:- > > > If you are going to say that the extra argument to the thm command > > must be processed in the same way, then you are going to have > > to extend the OpenTheory virtual machine to include the theorem > > metadata, so that you can define that processing. Were you planning > > to do that? > > No, I wasn't: my intention was that the theorem meta-data would be > interpreted in a reader-dependent way. The proposal was merely a > standard format for representing meta-data as finite maps represented > by nested lists of names, not processing it. > > > If you weren't planning to change the virtual machine, then > > this seems to me like a good candidate for a standardised > > pragma as Mario suggests. > > It would certainly be possible to specify theorem meta-data using > pragmas, and perhaps this is after all the best way to do it. > > However, in the spirit of yesterday's unsolicited philosophy lecture, > I would like to take a stand against "standardized pragmas". Once a > particular pragma has demonstrated its usefulness, my favoured > approach would be to define a new command in the next version of the > article spec standardizing its behaviour, rather than adding it to a > set of standardized pragmas. This is what I meant when I said I saw > pragmas as an experimental laboratory for new commands. > > Given this approach, there is no standardized behaviour for pragmas, > and so the opentheory tool does not have the information to maintain > them in articles it processes. Consider maintaining a "debug" pragma > during processing that compresses an article by merging equivalent > objects, or maintaining a "thmName" pragma during processing that > reorders the exported theorems. > > My theorem meta-data proposal was an attempt to standardize the > behaviour of thmName as a new command (i.e., the existing thm command > with an extra argument) so that the opentheory tool could maintain the > information during processing, but this discussion is persuading me > that the benefit of the change may not be worth its cost. > > 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 joe at gilith.com Sun Nov 9 06:44:11 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 8 Nov 2014 22:44:11 -0800 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: Hi Mario, Reading your post, thank you for clarifying the "pragmas can't change the state but all other commands must" position, which I agree with in essence. Also, I think I may have been misleading in my earlier email. My proposal would certainly involve changing the type of the exported theorems from thm set to (thm, metadata) finite_map in the definition of the virtual machine, and so my proposed extra argument to the thm command indeed have an effect on the state of the virtual machine. When I said the behaviour would be reader-dependent I misspoke, the article reader would have defined behaviour, but how the theorem metadata was processed would depend on the theorem prover implementation. The proposed type of exported theorems above makes it clear that we need a way to merge metadata if two alpha-equivalent theorems are exported. It also shows that two different theorems may have identical metadata without causing confusion. Cheers, Joe On Sat, Nov 8, 2014 at 5:25 PM, Mario Carneiro wrote: > I think I'm starting to see the philosophical distinction that Rob is trying > to make. The main body of commands in the current spec all change the state > of the OT virtual machine in some way, with the only exception being the > "pragma" command, which by contrast is required *not* to change anything > which is tracked by the virtual machine. That is, you are not allowed to > define a pragma that puts something on the stack, because then the machine > wouldn't operate correctly if you took the command out or used a reader that > didn't respect that pragma. The idea is simply to make this division remain > true in later versions of the standard. > > Thus, "debug" can never be made an official command, because unless standard > out is made a part of the virtual machine, it will always be a no-op with > respect to the state variables which *are* in the virtual machine > specification. Similarly, "thmName" can only be made an official command if > the exported theorem list in the virtual machine state contains name > information. > > In this case, it seems that the best way to incorporate "metadata" the way > you are trying to do would involve a new type annotated_thm, which contains > a thm object and a map of name -> object entries. The virtual machine > assumption list would still be a list of thm, but the theorem list would be > a list of annotated_thm, and your two-argument "thm" command would package > the theorem and metadata together and appendthe resulting annotated_thm > object to the theorem list. > > This way, it becomes mandatory to respect the metadata of a theorem in order > to have correct semantics, so by the above-mentioned philosophy it would > have to be an "official" command and not a pragma. Under the current model > of the virtual machine, any metadata would have to be tracked outside the > machine itself, which falls under the behavior of a pragma. > > One more remark: this is not a concern for article readers, but what should > an article merger do if the theorem is mentioned with the same metadata key > and different values? Your merging algorithm only works if the metadata is > for different keys or is the same in both theorem objects. > > Mario > > On Sat, Nov 8, 2014 at 7:24 PM, Joe Leslie-Hurd wrote: >> >> Hi Rob, >> >> > I am looking forward to seeing how this works out when I finish >> > upgrading my reader/writer for ProofPower to version 6. Will >> > it be possible to do the conversion with the opentheory tool >> > as a filter (so a script to import an article can just convert it >> > to its preferred version on the fly)? >> >> Indeed, this is already supported. This command reads an article (of >> any version) from stdin and writes an equivalent article on stdout >> using version 6: >> >> opentheory info --article --output-version 6 article:- >> >> > If you are going to say that the extra argument to the thm command >> > must be processed in the same way, then you are going to have >> > to extend the OpenTheory virtual machine to include the theorem >> > metadata, so that you can define that processing. Were you planning >> > to do that? >> >> No, I wasn't: my intention was that the theorem meta-data would be >> interpreted in a reader-dependent way. The proposal was merely a >> standard format for representing meta-data as finite maps represented >> by nested lists of names, not processing it. >> >> > If you weren't planning to change the virtual machine, then >> > this seems to me like a good candidate for a standardised >> > pragma as Mario suggests. >> >> It would certainly be possible to specify theorem meta-data using >> pragmas, and perhaps this is after all the best way to do it. >> >> However, in the spirit of yesterday's unsolicited philosophy lecture, >> I would like to take a stand against "standardized pragmas". Once a >> particular pragma has demonstrated its usefulness, my favoured >> approach would be to define a new command in the next version of the >> article spec standardizing its behaviour, rather than adding it to a >> set of standardized pragmas. This is what I meant when I said I saw >> pragmas as an experimental laboratory for new commands. >> >> Given this approach, there is no standardized behaviour for pragmas, >> and so the opentheory tool does not have the information to maintain >> them in articles it processes. Consider maintaining a "debug" pragma >> during processing that compresses an article by merging equivalent >> objects, or maintaining a "thmName" pragma during processing that >> reorders the exported theorems. >> >> My theorem meta-data proposal was an attempt to standardize the >> behaviour of thmName as a new command (i.e., the existing thm command >> with an extra argument) so that the opentheory tool could maintain the >> information during processing, but this discussion is persuading me >> that the benefit of the change may not be worth its cost. >> >> Cheers, >> >> Joe >> >> _______________________________________________ >> 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 di.gama at gmail.com Sun Nov 9 06:59:23 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 9 Nov 2014 01:59:23 -0500 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: > The proposed type of exported theorems above makes it clear that we > need a way to merge metadata if two alpha-equivalent theorems are > exported. It also shows that two different theorems may have identical > metadata without causing confusion. > This made me realize a potential issue in the current spec and even the version 5 spec: the theorem export list is described as a "set", even though my own implementation just treats it as a list. What is supposed to happen if you export two alpha-equivalent theorems? Do you keep them both, or throw away the original one or the new one? With metadata, this becomes still more complicated. My java implementation would have issues with using a HashMap for the thm keys of that map, because I have no hash function that respects alpha-equivalence. And if there are two alpha-equivalent theorems being exported in the same file, then that means that article readers too will have to handle metadata merging. Incidentally, are you in agreement with using a name -> object finite_map for the metadata? Using names seems the easiest way to build in namespaces the way you were originally thinking, and works well with the rest of the machine. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Nov 9 07:54:09 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 8 Nov 2014 23:54:09 -0800 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: Hi Mario, > This made me realize a potential issue in the current spec and even the > version 5 spec: the theorem export list is described as a "set", even though > my own implementation just treats it as a list. What is supposed to happen > if you export two alpha-equivalent theorems? Actually now I think about it alpha-equivalence is not relevant here. The thm command specifies a particular representative of the alpha-equivalence class, and that is exported from the article. So really the question becomes: what happens if you export two identical theorems, and the answer is that they get merged and only one of them is exported (it doesn't matter which). > With metadata, this becomes still more > complicated. With metadata only one of the theorems is exported like before, and its associated metadata would be formed by merging the metadata associated with the two theorems. > My java implementation would have issues with using a HashMap > for the thm keys of that map, because I have no hash function that respects > alpha-equivalence. For the reason above, this shouldn't be a problem. > Incidentally, are you in agreement with using a name -> object finite_map > for the metadata? Actually my proposal in http://www.gilith.com/pipermail/opentheory-users/2014-November/000438.html was to use metadata with the following ML syntax datatype metadata = Metadata of (name, metadata) finite_map; represented using article lists, so for example the metadata name: head_def HOLLight: name: HD simplifier would be represented as [["name",[["head_def",[]]]], ["HOLLight",[["name",[["HD",[]]],["simplifier",[]]]]] Merging two pieces of metadata would simply be the union of two finite maps, where if they map the same name then the inner finite maps are merged recursively. This has the desired idempotence property. The reason I don't want to use (name,object) finite_map is that objects can contain theorems and other data that affect logical dependencies between theories, and one of my design goals for metadata was to be transparent with respect to logical dependencies. The above scheme just involves names and lists, which has no effect on logical dependencies. Cheers, Joe From joe at gilith.com Mon Nov 10 15:48:07 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 10 Nov 2014 07:48:07 -0800 Subject: [opentheory-users] update command In-Reply-To: References: <776F0B03-7E49-4277-9D3D-8E8B02536D1F@lemma-one.com> Message-ID: I'm just cleaning up some old email, and I wanted to close this feature request. The opentheory tool now supports an upgrade command, which has the following help: $ opentheory upgrade -h opentheory: displaying option information usage: opentheory upgrade [upgrade options] QUERY Upgrade packages with later versions on a repo. Displaying upgrade options: -- ............... no more options -?, -h, --help ... display option information and exit -v, --version .... display version information QUERY is a package query (e.g., NAME or Upgradable). NAME is a package name (e.g., base). If the QUERY argument is missing all installed packages are upgraded. You still use opentheory list Upgradable to see which theory packages are able to be upgraded, but now actually upgrading them all is a simple matter of typing opentheory upgrade Or if you want to upgrade specific packages, then for example: opentheory upgrade natural-fibonacci Cheers, Joe On Tue, Mar 18, 2014 at 11:32 AM, Joe Leslie-Hurd wrote: > 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 >> > From joe at gilith.com Wed Nov 19 18:41:06 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 19 Nov 2014 10:41:06 -0800 Subject: [opentheory-users] Theorem meta-data In-Reply-To: References: <472CFF64-5DEE-4FEA-8B0F-9AB2EB4F12A0@lemma-one.com> Message-ID: Since the proposal for attaching metadata to exported theorems did not generate much enthusiasm, I propose shelving the idea for consideration when developing future versions of the article spec. Cheers, Joe On Sat, Nov 8, 2014 at 11:54 PM, Joe Leslie-Hurd wrote: > Hi Mario, > >> This made me realize a potential issue in the current spec and even the >> version 5 spec: the theorem export list is described as a "set", even though >> my own implementation just treats it as a list. What is supposed to happen >> if you export two alpha-equivalent theorems? > > Actually now I think about it alpha-equivalence is not relevant here. > The thm command specifies a particular representative of the > alpha-equivalence class, and that is exported from the article. So > really the question becomes: what happens if you export two identical > theorems, and the answer is that they get merged and only one of them > is exported (it doesn't matter which). > >> With metadata, this becomes still more >> complicated. > > With metadata only one of the theorems is exported like before, and > its associated metadata would be formed by merging the metadata > associated with the two theorems. > >> My java implementation would have issues with using a HashMap >> for the thm keys of that map, because I have no hash function that respects >> alpha-equivalence. > > For the reason above, this shouldn't be a problem. > >> Incidentally, are you in agreement with using a name -> object finite_map >> for the metadata? > > Actually my proposal in > > http://www.gilith.com/pipermail/opentheory-users/2014-November/000438.html > > was to use metadata with the following ML syntax > > datatype metadata = Metadata of (name, metadata) finite_map; > > represented using article lists, so for example the metadata > > name: head_def > HOLLight: > name: HD > simplifier > > would be represented as > > [["name",[["head_def",[]]]], > ["HOLLight",[["name",[["HD",[]]],["simplifier",[]]]]] > > Merging two pieces of metadata would simply be the union of two finite > maps, where if they map the same name then the inner finite maps are > merged recursively. This has the desired idempotence property. > > The reason I don't want to use (name,object) finite_map is that > objects can contain theorems and other data that affect logical > dependencies between theories, and one of my design goals for metadata > was to be transparent with respect to logical dependencies. The above > scheme just involves names and lists, which has no effect on logical > dependencies. > > Cheers, > > Joe From joe at gilith.com Wed Nov 19 18:45:27 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 19 Nov 2014 10:45:27 -0800 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: Message-ID: With the demise of the theorem metadata proposal there are no open features for version 6 of the article spec, and so I move to close the spec and make it official. At this point any future development will be for version 7 of the article spec. If I don't hear any objections I'll do this in the next day or so and release a version of the standard theory library in version 6 format. Cheers, Joe On Wed, Nov 5, 2014 at 11:23 PM, Mario Carneiro wrote: > Oh wow, that's a pretty direct derivation of extensionality from my version > of defineTypeOp. I stand corrected; certainly it's not desirable to have a > "conservative extension" allow the derivation of an axiom before its > introduction. And I guess that the next best thing if you want to maintain > conservativity is exactly your version of the axiom. > > Mario > > On Thu, Nov 6, 2014 at 2:16 AM, Joe Leslie-Hurd wrote: >> >> Hi Mario, >> >> As you say, extensionality is an axiom of the system, but the use of >> it is explicitly tracked. For example, you can see which theorems in >> bool theory depend on it using the following command: >> >> opentheory info --theory --show-assumptions --show-derivations bool >> >> If defineTypeOp produced this: >> >> ? p = (\r. rep (abs r) = r) (1) >> >> then you could apply appThm, betaConv and absThm to get: >> >> ? (\r. p r) = (\r. rep (abs r) = r) (2) >> >> and then sym and trans using (1) and (2) to get >> >> ? (\r. p r) = p (3) >> >> which is an untracked application of extensionality for any non-empty >> predicate p. It seemed more elegant to reformulate the theorem to >> avoid this possibility. >> >> Cheers, >> >> Joe >> >> On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: >> > I was aware that equation (1) is stronger than (2) without >> > extensionality, >> > but I'm curious why this is a problem, since it is an axiom of the >> > system >> > and doesn't require proof. Any v5 proof that starts with (2) can easily >> > be >> > rebuilt to use (1), while conversely for a v6 proof there are very few >> > theorems that follow from (1) but not (2) in the absence of >> > extensionality >> > (mostly trivial restatements of (1) itself), and I expect that any proof >> > that starts from (1) will immediately wrap it with appThm, upon which >> > point >> > it will again be equivalent to (2). >> > >> > Mario >> > >> > On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: >> >> >> >> Now that there is a release of the opentheory tool for processing >> >> version 6 articles, and I am sitting on a release of the standard >> >> theory library that uses version 6 articles, I'd like to finalize >> >> version 6 of the article file format standard, which is currently in >> >> draft mode: >> >> >> >> http://www.gilith.com/research/opentheory/article.html >> >> >> >> The commands that are new in version 6 are highlighted in yellow and >> >> the command with changed semantics (defineTypeOp) is highlighted in >> >> red. We have discussed the changes on this list, so there shouldn't be >> >> any surprises in store. >> >> >> >> Actually, there is one minor change that hasn't been discussed before. >> >> During implementation work on defineTypeOp I discovered that one of >> >> Mario's proposed theorems >> >> >> >> ? p = (\r. rep (abs r) = r) (1) >> >> >> >> required the axiom of extensionality to be logically equivalent to the >> >> same theorem produced by version 5 of defineTypeOp: >> >> >> >> ? p r = (rep (abs r) = r) (2) >> >> >> >> Although it would be theoretically possible to invoke the axiom of >> >> extensionality to convert between the two versions of defineTypeOp, I >> >> thought it was more elegant to reformulate theorem (1) >> >> by eta-expanding p: >> >> >> >> ? (\r. rep (abs r) = r) = \r. p r (3) >> >> >> >> [I also flipped the LHS and RHS so that theorem (3) has a pleasing >> >> similarity to the other theorem produced by defineTypeOp.] Now theorem >> >> (3) is logically equivalent to theorem (2) without requiring the axiom >> >> of extensionality, and retains the desirable property of having no >> >> free term variables. >> >> >> >> Anyway, there are no other "brown bag updates" to the standard, and >> >> I'd like to finalize it so we can start using it for real work. >> >> >> >> Does anybody have any objections or last-minute additions? >> >> >> >> Cheers, >> >> >> >> Joe >> >> >> >> _______________________________________________ >> >> 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 rda at lemma-one.com Wed Nov 19 20:12:48 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 19 Nov 2014 20:12:48 +0000 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: Message-ID: <46476981-9915-4869-8421-257095CCBDB2@lemma-one.com> Joe, I think it is prudent to leave the metadata proposal in the test lab for now. Is there ongoing work on interchange with Haskell? If part of your plan for the metadata was to do with mapping to the modularity features of other languages, then maybe that would be something that could be usefully addressed with some support from the theory format as well as or instead of the article format. I have no objection to version 6 going live. Do you think it would be worth recording the reasons for the changes somewhere? I don?t mind volunteering to collect the information. Thanks for all your hard work on this. Regards, Rob. On 19 Nov 2014, at 18:45, Joe Leslie-Hurd wrote: > With the demise of the theorem metadata proposal there are no open > features for version 6 of the article spec, and so I move to close the > spec and make it official. At this point any future development will > be for version 7 of the article spec. > > If I don't hear any objections I'll do this in the next day or so and > release a version of the standard theory library in version 6 format. > > Cheers, > > Joe > > On Wed, Nov 5, 2014 at 11:23 PM, Mario Carneiro wrote: >> Oh wow, that's a pretty direct derivation of extensionality from my version >> of defineTypeOp. I stand corrected; certainly it's not desirable to have a >> "conservative extension" allow the derivation of an axiom before its >> introduction. And I guess that the next best thing if you want to maintain >> conservativity is exactly your version of the axiom. >> >> Mario >> >> On Thu, Nov 6, 2014 at 2:16 AM, Joe Leslie-Hurd wrote: >>> >>> Hi Mario, >>> >>> As you say, extensionality is an axiom of the system, but the use of >>> it is explicitly tracked. For example, you can see which theorems in >>> bool theory depend on it using the following command: >>> >>> opentheory info --theory --show-assumptions --show-derivations bool >>> >>> If defineTypeOp produced this: >>> >>> ? p = (\r. rep (abs r) = r) (1) >>> >>> then you could apply appThm, betaConv and absThm to get: >>> >>> ? (\r. p r) = (\r. rep (abs r) = r) (2) >>> >>> and then sym and trans using (1) and (2) to get >>> >>> ? (\r. p r) = p (3) >>> >>> which is an untracked application of extensionality for any non-empty >>> predicate p. It seemed more elegant to reformulate the theorem to >>> avoid this possibility. >>> >>> Cheers, >>> >>> Joe >>> >>> On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: >>>> I was aware that equation (1) is stronger than (2) without >>>> extensionality, >>>> but I'm curious why this is a problem, since it is an axiom of the >>>> system >>>> and doesn't require proof. Any v5 proof that starts with (2) can easily >>>> be >>>> rebuilt to use (1), while conversely for a v6 proof there are very few >>>> theorems that follow from (1) but not (2) in the absence of >>>> extensionality >>>> (mostly trivial restatements of (1) itself), and I expect that any proof >>>> that starts from (1) will immediately wrap it with appThm, upon which >>>> point >>>> it will again be equivalent to (2). >>>> >>>> Mario >>>> >>>> On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: >>>>> >>>>> Now that there is a release of the opentheory tool for processing >>>>> version 6 articles, and I am sitting on a release of the standard >>>>> theory library that uses version 6 articles, I'd like to finalize >>>>> version 6 of the article file format standard, which is currently in >>>>> draft mode: >>>>> >>>>> http://www.gilith.com/research/opentheory/article.html >>>>> >>>>> The commands that are new in version 6 are highlighted in yellow and >>>>> the command with changed semantics (defineTypeOp) is highlighted in >>>>> red. We have discussed the changes on this list, so there shouldn't be >>>>> any surprises in store. >>>>> >>>>> Actually, there is one minor change that hasn't been discussed before. >>>>> During implementation work on defineTypeOp I discovered that one of >>>>> Mario's proposed theorems >>>>> >>>>> ? p = (\r. rep (abs r) = r) (1) >>>>> >>>>> required the axiom of extensionality to be logically equivalent to the >>>>> same theorem produced by version 5 of defineTypeOp: >>>>> >>>>> ? p r = (rep (abs r) = r) (2) >>>>> >>>>> Although it would be theoretically possible to invoke the axiom of >>>>> extensionality to convert between the two versions of defineTypeOp, I >>>>> thought it was more elegant to reformulate theorem (1) >>>>> by eta-expanding p: >>>>> >>>>> ? (\r. rep (abs r) = r) = \r. p r (3) >>>>> >>>>> [I also flipped the LHS and RHS so that theorem (3) has a pleasing >>>>> similarity to the other theorem produced by defineTypeOp.] Now theorem >>>>> (3) is logically equivalent to theorem (2) without requiring the axiom >>>>> of extensionality, and retains the desirable property of having no >>>>> free term variables. >>>>> >>>>> Anyway, there are no other "brown bag updates" to the standard, and >>>>> I'd like to finalize it so we can start using it for real work. >>>>> >>>>> Does anybody have any objections or last-minute additions? >>>>> >>>>> Cheers, >>>>> >>>>> Joe >>>>> >>>>> _______________________________________________ >>>>> 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 Nov 19 21:02:05 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 19 Nov 2014 13:02:05 -0800 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: <46476981-9915-4869-8421-257095CCBDB2@lemma-one.com> References: <46476981-9915-4869-8421-257095CCBDB2@lemma-one.com> Message-ID: Hi Rob, I am indeed working on the Haskell export functionality and I thought that the theorem metadata might help with this, but for now I plan on using theory files to record the necessary information. The only plan I have for recording the changes is to keep a copy of the current article spec (with highlighting) to make it easy to see what has changed. I would then remove the highlighting in the official version 6 spec so we can start with a blank slate when discussing possible changes toward a version 7. I would be happy to take you up on your offer to collect the reasons for changing the format. How do you think it is best to record the reasons for the changes? As part of an announcement on this mailing list? As annotations in the version of the article spec with the changes highlighted? Cheers, Joe On Wed, Nov 19, 2014 at 12:12 PM, Rob Arthan wrote: > Joe, > > I think it is prudent to leave the metadata proposal in the test lab for > now. > Is there ongoing work on interchange with Haskell? If part of your plan > for the metadata was to do with mapping to the modularity features of other > languages, then maybe that would be something that could be usefully > addressed > with some support from the theory format as well as or instead of the > article format. > > I have no objection to version 6 going live. Do you think it would be worth > recording the reasons for the changes somewhere? I don?t mind volunteering > to collect the information. > > Thanks for all your hard work on this. > > Regards, > > Rob. > > > On 19 Nov 2014, at 18:45, Joe Leslie-Hurd wrote: > > With the demise of the theorem metadata proposal there are no open > features for version 6 of the article spec, and so I move to close the > spec and make it official. At this point any future development will > be for version 7 of the article spec. > > If I don't hear any objections I'll do this in the next day or so and > release a version of the standard theory library in version 6 format. > > Cheers, > > Joe > > On Wed, Nov 5, 2014 at 11:23 PM, Mario Carneiro wrote: > > Oh wow, that's a pretty direct derivation of extensionality from my version > of defineTypeOp. I stand corrected; certainly it's not desirable to have a > "conservative extension" allow the derivation of an axiom before its > introduction. And I guess that the next best thing if you want to maintain > conservativity is exactly your version of the axiom. > > Mario > > On Thu, Nov 6, 2014 at 2:16 AM, Joe Leslie-Hurd wrote: > > > Hi Mario, > > As you say, extensionality is an axiom of the system, but the use of > it is explicitly tracked. For example, you can see which theorems in > bool theory depend on it using the following command: > > opentheory info --theory --show-assumptions --show-derivations bool > > If defineTypeOp produced this: > > ? p = (\r. rep (abs r) = r) (1) > > then you could apply appThm, betaConv and absThm to get: > > ? (\r. p r) = (\r. rep (abs r) = r) (2) > > and then sym and trans using (1) and (2) to get > > ? (\r. p r) = p (3) > > which is an untracked application of extensionality for any non-empty > predicate p. It seemed more elegant to reformulate the theorem to > avoid this possibility. > > Cheers, > > Joe > > On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: > > I was aware that equation (1) is stronger than (2) without > extensionality, > but I'm curious why this is a problem, since it is an axiom of the > system > and doesn't require proof. Any v5 proof that starts with (2) can easily > be > rebuilt to use (1), while conversely for a v6 proof there are very few > theorems that follow from (1) but not (2) in the absence of > extensionality > (mostly trivial restatements of (1) itself), and I expect that any proof > that starts from (1) will immediately wrap it with appThm, upon which > point > it will again be equivalent to (2). > > Mario > > On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: > > > Now that there is a release of the opentheory tool for processing > version 6 articles, and I am sitting on a release of the standard > theory library that uses version 6 articles, I'd like to finalize > version 6 of the article file format standard, which is currently in > draft mode: > > http://www.gilith.com/research/opentheory/article.html > > The commands that are new in version 6 are highlighted in yellow and > the command with changed semantics (defineTypeOp) is highlighted in > red. We have discussed the changes on this list, so there shouldn't be > any surprises in store. > > Actually, there is one minor change that hasn't been discussed before. > During implementation work on defineTypeOp I discovered that one of > Mario's proposed theorems > > ? p = (\r. rep (abs r) = r) (1) > > required the axiom of extensionality to be logically equivalent to the > same theorem produced by version 5 of defineTypeOp: > > ? p r = (rep (abs r) = r) (2) > > Although it would be theoretically possible to invoke the axiom of > extensionality to convert between the two versions of defineTypeOp, I > thought it was more elegant to reformulate theorem (1) > by eta-expanding p: > > ? (\r. rep (abs r) = r) = \r. p r (3) > > [I also flipped the LHS and RHS so that theorem (3) has a pleasing > similarity to the other theorem produced by defineTypeOp.] Now theorem > (3) is logically equivalent to theorem (2) without requiring the axiom > of extensionality, and retains the desirable property of having no > free term variables. > > Anyway, there are no other "brown bag updates" to the standard, and > I'd like to finalize it so we can start using it for real work. > > Does anybody have any objections or last-minute additions? > > Cheers, > > Joe > > _______________________________________________ > 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 joe at gilith.com Mon Nov 24 17:37:13 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 24 Nov 2014 09:37:13 -0800 Subject: [opentheory-users] Finalizing version 6 of the article file format standard In-Reply-To: References: <46476981-9915-4869-8421-257095CCBDB2@lemma-one.com> Message-ID: Hi Rob, I've taken some steps in preparation for an announcement: 1. Version 6 of the article spec is now available at the following URLs: http://www.gilith.com/research/opentheory/article.html http://www.gilith.com/research/opentheory/article-6.html 2. The changes between version 5 and version 6 are highlighted at http://www.gilith.com/research/opentheory/article-5-6.html 3. A version of the standard theory library using version 6 articles is now on the public OpenTheory repo: http://opentheory.gilith.com/?pkg=base-1.169 You should be able to upgrade by simply typing opentheory update opentheory upgrade using the latest version of the opentheory tool. If you would like to write some text describing the changes in the article spec then I'll make an official announcement on this list. Cheers, Joe On Wed, Nov 19, 2014 at 1:02 PM, Joe Leslie-Hurd wrote: > Hi Rob, > > I am indeed working on the Haskell export functionality and I thought > that the theorem metadata might help with this, but for now I plan on > using theory files to record the necessary information. > > The only plan I have for recording the changes is to keep a copy of > the current article spec (with highlighting) to make it easy to see > what has changed. I would then remove the highlighting in the official > version 6 spec so we can start with a blank slate when discussing > possible changes toward a version 7. > > I would be happy to take you up on your offer to collect the reasons > for changing the format. How do you think it is best to record the > reasons for the changes? As part of an announcement on this mailing > list? As annotations in the version of the article spec with the > changes highlighted? > > Cheers, > > Joe > > On Wed, Nov 19, 2014 at 12:12 PM, Rob Arthan wrote: >> Joe, >> >> I think it is prudent to leave the metadata proposal in the test lab for >> now. >> Is there ongoing work on interchange with Haskell? If part of your plan >> for the metadata was to do with mapping to the modularity features of other >> languages, then maybe that would be something that could be usefully >> addressed >> with some support from the theory format as well as or instead of the >> article format. >> >> I have no objection to version 6 going live. Do you think it would be worth >> recording the reasons for the changes somewhere? I don?t mind volunteering >> to collect the information. >> >> Thanks for all your hard work on this. >> >> Regards, >> >> Rob. >> >> >> On 19 Nov 2014, at 18:45, Joe Leslie-Hurd wrote: >> >> With the demise of the theorem metadata proposal there are no open >> features for version 6 of the article spec, and so I move to close the >> spec and make it official. At this point any future development will >> be for version 7 of the article spec. >> >> If I don't hear any objections I'll do this in the next day or so and >> release a version of the standard theory library in version 6 format. >> >> Cheers, >> >> Joe >> >> On Wed, Nov 5, 2014 at 11:23 PM, Mario Carneiro wrote: >> >> Oh wow, that's a pretty direct derivation of extensionality from my version >> of defineTypeOp. I stand corrected; certainly it's not desirable to have a >> "conservative extension" allow the derivation of an axiom before its >> introduction. And I guess that the next best thing if you want to maintain >> conservativity is exactly your version of the axiom. >> >> Mario >> >> On Thu, Nov 6, 2014 at 2:16 AM, Joe Leslie-Hurd wrote: >> >> >> Hi Mario, >> >> As you say, extensionality is an axiom of the system, but the use of >> it is explicitly tracked. For example, you can see which theorems in >> bool theory depend on it using the following command: >> >> opentheory info --theory --show-assumptions --show-derivations bool >> >> If defineTypeOp produced this: >> >> ? p = (\r. rep (abs r) = r) (1) >> >> then you could apply appThm, betaConv and absThm to get: >> >> ? (\r. p r) = (\r. rep (abs r) = r) (2) >> >> and then sym and trans using (1) and (2) to get >> >> ? (\r. p r) = p (3) >> >> which is an untracked application of extensionality for any non-empty >> predicate p. It seemed more elegant to reformulate the theorem to >> avoid this possibility. >> >> Cheers, >> >> Joe >> >> On Wed, Nov 5, 2014 at 10:45 PM, Mario Carneiro wrote: >> >> I was aware that equation (1) is stronger than (2) without >> extensionality, >> but I'm curious why this is a problem, since it is an axiom of the >> system >> and doesn't require proof. Any v5 proof that starts with (2) can easily >> be >> rebuilt to use (1), while conversely for a v6 proof there are very few >> theorems that follow from (1) but not (2) in the absence of >> extensionality >> (mostly trivial restatements of (1) itself), and I expect that any proof >> that starts from (1) will immediately wrap it with appThm, upon which >> point >> it will again be equivalent to (2). >> >> Mario >> >> On Thu, Nov 6, 2014 at 1:31 AM, Joe Leslie-Hurd wrote: >> >> >> Now that there is a release of the opentheory tool for processing >> version 6 articles, and I am sitting on a release of the standard >> theory library that uses version 6 articles, I'd like to finalize >> version 6 of the article file format standard, which is currently in >> draft mode: >> >> http://www.gilith.com/research/opentheory/article.html >> >> The commands that are new in version 6 are highlighted in yellow and >> the command with changed semantics (defineTypeOp) is highlighted in >> red. We have discussed the changes on this list, so there shouldn't be >> any surprises in store. >> >> Actually, there is one minor change that hasn't been discussed before. >> During implementation work on defineTypeOp I discovered that one of >> Mario's proposed theorems >> >> ? p = (\r. rep (abs r) = r) (1) >> >> required the axiom of extensionality to be logically equivalent to the >> same theorem produced by version 5 of defineTypeOp: >> >> ? p r = (rep (abs r) = r) (2) >> >> Although it would be theoretically possible to invoke the axiom of >> extensionality to convert between the two versions of defineTypeOp, I >> thought it was more elegant to reformulate theorem (1) >> by eta-expanding p: >> >> ? (\r. rep (abs r) = r) = \r. p r (3) >> >> [I also flipped the LHS and RHS so that theorem (3) has a pleasing >> similarity to the other theorem produced by defineTypeOp.] Now theorem >> (3) is logically equivalent to theorem (2) without requiring the axiom >> of extensionality, and retains the desirable property of having no >> free term variables. >> >> Anyway, there are no other "brown bag updates" to the standard, and >> I'd like to finalize it so we can start using it for real work. >> >> Does anybody have any objections or last-minute additions? >> >> Cheers, >> >> Joe >> >> _______________________________________________ >> 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 joe at gilith.com Mon Nov 24 19:13:08 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 24 Nov 2014 11:13:08 -0800 Subject: [opentheory-users] Local definitions in theory packages Message-ID: There have been several discussions on this list about symbols (i.e., type operators and constants) that are defined in a theory but are not mentioned in any exported theorem, which Rob named local definitions. Since most of the HOL family of theorem provers maintain a global symbol table, these local definitions can cause problems if they have clashing names. Up until now it's been difficult to see the complete set of symbols referred to inside a theory, but this can now be displayed with the opentheory info --symbols command (I append the output for the most recent version of the standard theory library: base-1.169). As can be seen, most of the local definitions (which are the symbols in the HOLLight namespace) are abstraction and representation functions for type definitions, but there are also others such as those that are used to construct the real numbers. In my opinion it would make theories more elegant if (some of) these local definitions could be removed, but in the meantime I'd like to know of any instances with clashing local definitions (these could occur either in the same theory or across different theories). My current belief is that these should be easy to fix in a natural way, but I need to see some concrete examples. Cheers, Joe ______________________________________________________ $ opentheory info --symbols base 3 external type operators: -> bool ind 2 external constants: = select 11 defined type operators: Data.List.list Data.Option.option Data.Pair.* Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd HOLLight.recspace Number.Natural.natural Number.Real.real Set.set 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: Data.List.@ Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: Data.List.concat Data.List.drop Data.List.filter Data.List.foldl Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval Data.List.last Data.List.length Data.List.map Data.List.member Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null Data.List.replicate Data.List.reverse Data.List.tail Data.List.take Data.List.toSet Data.List.zip Data.List.zipWith Data.Option.case.none.some Data.Option.isNone Data.Option.isSome Data.Option.map Data.Option.none Data.Option.some Data.Pair., Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right Data.Sum.destLeft Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip Function.id Function.injective Function.o Function.surjective Function.Combinator.s Function.Combinator.w HOLLight._dest_list HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec HOLLight._mk_sum HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal HOLLight.mk_nadd HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS HOLLight.one_REP HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv HOLLight.treal_le HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP HOLLight.NUMFST HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 Number.Natural.bit1 Number.Natural.distance Number.Natural.div Number.Natural.even Number.Natural.factorial Number.Natural.isSuc Number.Natural.log Number.Natural.max Number.Natural.min Number.Natural.minimal Number.Natural.mod Number.Natural.odd Number.Natural.pre Number.Natural.suc Number.Natural.zero Number.Real.* Number.Real.+ Number.Real.- Number.Real./ Number.Real.< Number.Real.<= Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ Number.Real.abs Number.Real.fromNatural Number.Real.inv Number.Real.max Number.Real.min Number.Real.sup Relation.bigIntersect Relation.bigUnion Relation.empty Relation.fromSet Relation.intersect Relation.irreflexive Relation.measure Relation.reflexive Relation.subrelation Relation.toSet Relation.transitive Relation.transitiveClosure Relation.union Relation.universe Relation.wellFounded Set.{} Set.bigIntersect Set.bigUnion Set.bijections Set.choice Set.cross Set.delete Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate Set.hasSize Set.image Set.infinite Set.injections Set.insert Set.intersect Set.member Set.properSubset Set.rest Set.singleton Set.size Set.subset Set.surjections Set.union Set.universe From di.gama at gmail.com Mon Nov 24 19:32:36 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 24 Nov 2014 14:32:36 -0500 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: I expect that it will be impossible to remove most of the local definitions that you are talking about, because they serve an important purpose: they are useful for "forgetting" about constructions. Once you've proven that the reals have the desired properties, it no longer becomes important what sequence of embeddings was used to build the Real type in the first place, and indeed there is an aesthetic in proofs which avoid any reference to such "construction-dependent" properties. (This process is made explicit in Metamath, where we derive the basic properties of the reals, then ignore these proofs and replace them with axioms so that you can't use the construction any more but are forced to use only the properties.) A similar argument applies to the abstraction and representation functions - unless you are going to be moving between the types often, you may as well forget about these functions once the basic properties of the new type are established. These are new constants whose construction is mandated by the language. You can't make a new type without getting abs,rep functions out. You can't construct a derived type without constructing the base type first. Once you have the constants, but you no longer need them, what are you supposed to do with them? Mario On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd wrote: > There have been several discussions on this list about symbols (i.e., > type operators and constants) that are defined in a theory but are not > mentioned in any exported theorem, which Rob named local definitions. > Since most of the HOL family of theorem provers maintain a global > symbol table, these local definitions can cause problems if they have > clashing names. > > Up until now it's been difficult to see the complete set of symbols > referred to inside a theory, but this can now be displayed with the > opentheory info --symbols command (I append the output for the most > recent version of the standard theory library: base-1.169). As can be > seen, most of the local definitions (which are the symbols in the > HOLLight namespace) are abstraction and representation functions for > type definitions, but there are also others such as those that are > used to construct the real numbers. > > In my opinion it would make theories more elegant if (some of) these > local definitions could be removed, but in the meantime I'd like to > know of any instances with clashing local definitions (these could > occur either in the same theory or across different theories). My > current belief is that these should be easy to fix in a natural way, > but I need to see some concrete examples. > > Cheers, > > Joe > > ______________________________________________________ > > $ opentheory info --symbols base > 3 external type operators: -> bool ind > 2 external constants: = select > 11 defined type operators: Data.List.list Data.Option.option Data.Pair.* > Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd HOLLight.recspace > Number.Natural.natural Number.Real.real Set.set > 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: Data.List.@ > Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: > Data.List.concat Data.List.drop Data.List.filter Data.List.foldl > Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval > Data.List.last Data.List.length Data.List.map Data.List.member > Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null > Data.List.replicate Data.List.reverse Data.List.tail Data.List.take > Data.List.toSet Data.List.zip Data.List.zipWith > Data.Option.case.none.some Data.Option.isNone Data.Option.isSome > Data.Option.map Data.Option.none Data.Option.some Data.Pair., > Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right Data.Sum.destLeft > Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left > Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip > Function.id Function.injective Function.o Function.surjective > Function.Combinator.s Function.Combinator.w HOLLight._dest_list > HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum > HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec HOLLight._mk_sum > HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num > HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add > HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul > HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal HOLLight.mk_nadd > HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add > HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul > HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS HOLLight.one_REP > HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv HOLLight.treal_le > HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num > HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS > HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC > HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP HOLLight.NUMFST > HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND > HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT > HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ > Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> > Number.Natural.>= Number.Natural.^ Number.Natural.bit0 > Number.Natural.bit1 Number.Natural.distance Number.Natural.div > Number.Natural.even Number.Natural.factorial Number.Natural.isSuc > Number.Natural.log Number.Natural.max Number.Natural.min > Number.Natural.minimal Number.Natural.mod Number.Natural.odd > Number.Natural.pre Number.Natural.suc Number.Natural.zero Number.Real.* > Number.Real.+ Number.Real.- Number.Real./ Number.Real.< Number.Real.<= > Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ Number.Real.abs > Number.Real.fromNatural Number.Real.inv Number.Real.max Number.Real.min > Number.Real.sup Relation.bigIntersect Relation.bigUnion Relation.empty > Relation.fromSet Relation.intersect Relation.irreflexive Relation.measure > Relation.reflexive Relation.subrelation Relation.toSet > Relation.transitive Relation.transitiveClosure Relation.union > Relation.universe Relation.wellFounded Set.{} Set.bigIntersect > Set.bigUnion Set.bijections Set.choice Set.cross Set.delete > Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate > Set.hasSize Set.image Set.infinite Set.injections Set.insert > Set.intersect Set.member Set.properSubset Set.rest Set.singleton Set.size > Set.subset Set.surjections Set.union Set.universe > > _______________________________________________ > 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 konrad.slind at gmail.com Mon Nov 24 19:49:34 2014 From: konrad.slind at gmail.com (Konrad Slind) Date: Mon, 24 Nov 2014 13:49:34 -0600 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: It's a scoping issue. I think that Peter Homeier's HOL-Omega can quantify/bind the local constants used to construct datatypes, for example. So its rules may provide guidance on what OpenTheory should do. Sorry, I know I am not answering the original question. Konrad. On Mon, Nov 24, 2014 at 1:32 PM, Mario Carneiro wrote: > I expect that it will be impossible to remove most of the local > definitions that you are talking about, because they serve an important > purpose: they are useful for "forgetting" about constructions. Once you've > proven that the reals have the desired properties, it no longer becomes > important what sequence of embeddings was used to build the Real type in > the first place, and indeed there is an aesthetic in proofs which avoid any > reference to such "construction-dependent" properties. (This process is > made explicit in Metamath, where we derive the basic properties of the > reals, then ignore these proofs and replace them with axioms so that you > can't use the construction any more but are forced to use only the > properties.) A similar argument applies to the abstraction and > representation functions - unless you are going to be moving between the > types often, you may as well forget about these functions once the basic > properties of the new type are established. > > These are new constants whose construction is mandated by the language. > You can't make a new type without getting abs,rep functions out. You can't > construct a derived type without constructing the base type first. Once you > have the constants, but you no longer need them, what are you supposed to > do with them? > > Mario > > On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd wrote: > >> There have been several discussions on this list about symbols (i.e., >> type operators and constants) that are defined in a theory but are not >> mentioned in any exported theorem, which Rob named local definitions. >> Since most of the HOL family of theorem provers maintain a global >> symbol table, these local definitions can cause problems if they have >> clashing names. >> >> Up until now it's been difficult to see the complete set of symbols >> referred to inside a theory, but this can now be displayed with the >> opentheory info --symbols command (I append the output for the most >> recent version of the standard theory library: base-1.169). As can be >> seen, most of the local definitions (which are the symbols in the >> HOLLight namespace) are abstraction and representation functions for >> type definitions, but there are also others such as those that are >> used to construct the real numbers. >> >> In my opinion it would make theories more elegant if (some of) these >> local definitions could be removed, but in the meantime I'd like to >> know of any instances with clashing local definitions (these could >> occur either in the same theory or across different theories). My >> current belief is that these should be easy to fix in a natural way, >> but I need to see some concrete examples. >> >> Cheers, >> >> Joe >> >> ______________________________________________________ >> >> $ opentheory info --symbols base >> 3 external type operators: -> bool ind >> 2 external constants: = select >> 11 defined type operators: Data.List.list Data.Option.option Data.Pair.* >> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd HOLLight.recspace >> Number.Natural.natural Number.Real.real Set.set >> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: >> Data.List.@ >> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: >> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl >> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval >> Data.List.last Data.List.length Data.List.map Data.List.member >> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null >> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take >> Data.List.toSet Data.List.zip Data.List.zipWith >> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome >> Data.Option.map Data.Option.none Data.Option.some Data.Pair., >> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right Data.Sum.destLeft >> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left >> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip >> Function.id Function.injective Function.o Function.surjective >> Function.Combinator.s Function.Combinator.w HOLLight._dest_list >> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum >> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec HOLLight._mk_sum >> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num >> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add >> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul >> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal >> HOLLight.mk_nadd >> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add >> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul >> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS >> HOLLight.one_REP >> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv >> HOLLight.treal_le >> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num >> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS >> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC >> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP HOLLight.NUMFST >> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND >> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT >> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ >> Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> >> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 >> Number.Natural.bit1 Number.Natural.distance Number.Natural.div >> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc >> Number.Natural.log Number.Natural.max Number.Natural.min >> Number.Natural.minimal Number.Natural.mod Number.Natural.odd >> Number.Natural.pre Number.Natural.suc Number.Natural.zero Number.Real.* >> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< Number.Real.<= >> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ Number.Real.abs >> Number.Real.fromNatural Number.Real.inv Number.Real.max Number.Real.min >> Number.Real.sup Relation.bigIntersect Relation.bigUnion Relation.empty >> Relation.fromSet Relation.intersect Relation.irreflexive >> Relation.measure >> Relation.reflexive Relation.subrelation Relation.toSet >> Relation.transitive Relation.transitiveClosure Relation.union >> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect >> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete >> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate >> Set.hasSize Set.image Set.infinite Set.injections Set.insert >> Set.intersect Set.member Set.properSubset Set.rest Set.singleton >> Set.size >> Set.subset Set.surjections Set.union Set.universe >> >> _______________________________________________ >> 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 Nov 24 19:49:51 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 24 Nov 2014 11:49:51 -0800 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: Hi Mario, I agree that local definitions serve an important need in forgetting about constructions, and I expect that it will be impossible to eliminate them completely. However, perhaps a future version of the article spec will incorporate Rob's new type operator specification principle which defines a new type without also defining abs/rep constants, and this will at least offer the theory developer a simple way to eliminate a large class of local definitions. Cheers, Joe On Mon, Nov 24, 2014 at 11:32 AM, Mario Carneiro wrote: > I expect that it will be impossible to remove most of the local definitions > that you are talking about, because they serve an important purpose: they > are useful for "forgetting" about constructions. Once you've proven that the > reals have the desired properties, it no longer becomes important what > sequence of embeddings was used to build the Real type in the first place, > and indeed there is an aesthetic in proofs which avoid any reference to such > "construction-dependent" properties. (This process is made explicit in > Metamath, where we derive the basic properties of the reals, then ignore > these proofs and replace them with axioms so that you can't use the > construction any more but are forced to use only the properties.) A similar > argument applies to the abstraction and representation functions - unless > you are going to be moving between the types often, you may as well forget > about these functions once the basic properties of the new type are > established. > > These are new constants whose construction is mandated by the language. You > can't make a new type without getting abs,rep functions out. You can't > construct a derived type without constructing the base type first. Once you > have the constants, but you no longer need them, what are you supposed to do > with them? > > Mario > > On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd wrote: >> >> There have been several discussions on this list about symbols (i.e., >> type operators and constants) that are defined in a theory but are not >> mentioned in any exported theorem, which Rob named local definitions. >> Since most of the HOL family of theorem provers maintain a global >> symbol table, these local definitions can cause problems if they have >> clashing names. >> >> Up until now it's been difficult to see the complete set of symbols >> referred to inside a theory, but this can now be displayed with the >> opentheory info --symbols command (I append the output for the most >> recent version of the standard theory library: base-1.169). As can be >> seen, most of the local definitions (which are the symbols in the >> HOLLight namespace) are abstraction and representation functions for >> type definitions, but there are also others such as those that are >> used to construct the real numbers. >> >> In my opinion it would make theories more elegant if (some of) these >> local definitions could be removed, but in the meantime I'd like to >> know of any instances with clashing local definitions (these could >> occur either in the same theory or across different theories). My >> current belief is that these should be easy to fix in a natural way, >> but I need to see some concrete examples. >> >> Cheers, >> >> Joe >> >> ______________________________________________________ >> >> $ opentheory info --symbols base >> 3 external type operators: -> bool ind >> 2 external constants: = select >> 11 defined type operators: Data.List.list Data.Option.option Data.Pair.* >> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd HOLLight.recspace >> Number.Natural.natural Number.Real.real Set.set >> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: >> Data.List.@ >> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: >> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl >> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval >> Data.List.last Data.List.length Data.List.map Data.List.member >> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null >> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take >> Data.List.toSet Data.List.zip Data.List.zipWith >> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome >> Data.Option.map Data.Option.none Data.Option.some Data.Pair., >> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right Data.Sum.destLeft >> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left >> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip >> Function.id Function.injective Function.o Function.surjective >> Function.Combinator.s Function.Combinator.w HOLLight._dest_list >> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum >> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec HOLLight._mk_sum >> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num >> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add >> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul >> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal >> HOLLight.mk_nadd >> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add >> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul >> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS >> HOLLight.one_REP >> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv >> HOLLight.treal_le >> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num >> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS >> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC >> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP HOLLight.NUMFST >> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND >> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT >> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ >> Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> >> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 >> Number.Natural.bit1 Number.Natural.distance Number.Natural.div >> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc >> Number.Natural.log Number.Natural.max Number.Natural.min >> Number.Natural.minimal Number.Natural.mod Number.Natural.odd >> Number.Natural.pre Number.Natural.suc Number.Natural.zero Number.Real.* >> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< Number.Real.<= >> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ Number.Real.abs >> Number.Real.fromNatural Number.Real.inv Number.Real.max Number.Real.min >> Number.Real.sup Relation.bigIntersect Relation.bigUnion Relation.empty >> Relation.fromSet Relation.intersect Relation.irreflexive >> Relation.measure >> Relation.reflexive Relation.subrelation Relation.toSet >> Relation.transitive Relation.transitiveClosure Relation.union >> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect >> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete >> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate >> Set.hasSize Set.image Set.infinite Set.injections Set.insert >> Set.intersect Set.member Set.properSubset Set.rest Set.singleton >> Set.size >> Set.subset Set.surjections Set.union Set.universe >> >> _______________________________________________ >> 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 Nov 24 22:19:52 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 24 Nov 2014 14:19:52 -0800 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: Hi Konrad, I agree that this is a scoping issue, but it seems like there are two kinds of scopes manifesting, which I shall call micro-scopes and macro-scopes. An example of micro-scopes are the abs/rep functions of HOL Light's type operator definition principle, and can be dealt with using a new inference rule that does not define extra constants (such as Rob's proposed new type definition or following Peter's approach in HOL-Omega). An example of macro-scopes is the construction of the real numbers, where you have to develop a big formalization (including definitions) to construct some mathematical object, and then you throw away that construction and export a few characteristic properties ("axioms"). This leaves a bunch of locally defined symbols in the theory (an example in the standard theory library is the HOLLight.hreal type). Cleaning up the micro-scopes is certainly desirable for a theory package designed to be shared between theorem provers, but I wonder how much it is possible to clean up the macro-scopes too? It would involve factoring the construction formalization into theories useful in their own right, rather than making definitions that are tailored to the construction of one particular mathematical object. In the case of the real numbers in HOL Light, one stepping stone is the construction of the positive real numbers (the "half-real" numbers represented by the HOLLight.hreal type above), which doesn't sound particularly useful in its own right, so would fail that test. I wonder if there is another construction of the real numbers that is based solely on generally useful mathematical objects? The one I remember from my undergraduate days makes the type definition real = rational set where each rational set must be downward-closed (i.e., if a rational set S contains x then S also contains every rational less than x). This construction might be more involved than the one in HOL Light, but has the advantage of being based only on generally useful objects (sets and rational numbers). Cheers, Joe On Mon, Nov 24, 2014 at 11:49 AM, Konrad Slind wrote: > It's a scoping issue. I think that Peter Homeier's HOL-Omega > can quantify/bind the local constants used to construct datatypes, > for example. So its rules may provide guidance on what OpenTheory > should do. > > Sorry, I know I am not answering the original question. > > Konrad. > > > On Mon, Nov 24, 2014 at 1:32 PM, Mario Carneiro wrote: >> >> I expect that it will be impossible to remove most of the local >> definitions that you are talking about, because they serve an important >> purpose: they are useful for "forgetting" about constructions. Once you've >> proven that the reals have the desired properties, it no longer becomes >> important what sequence of embeddings was used to build the Real type in the >> first place, and indeed there is an aesthetic in proofs which avoid any >> reference to such "construction-dependent" properties. (This process is made >> explicit in Metamath, where we derive the basic properties of the reals, >> then ignore these proofs and replace them with axioms so that you can't use >> the construction any more but are forced to use only the properties.) A >> similar argument applies to the abstraction and representation functions - >> unless you are going to be moving between the types often, you may as well >> forget about these functions once the basic properties of the new type are >> established. >> >> These are new constants whose construction is mandated by the language. >> You can't make a new type without getting abs,rep functions out. You can't >> construct a derived type without constructing the base type first. Once you >> have the constants, but you no longer need them, what are you supposed to do >> with them? >> >> Mario >> >> On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd wrote: >>> >>> There have been several discussions on this list about symbols (i.e., >>> type operators and constants) that are defined in a theory but are not >>> mentioned in any exported theorem, which Rob named local definitions. >>> Since most of the HOL family of theorem provers maintain a global >>> symbol table, these local definitions can cause problems if they have >>> clashing names. >>> >>> Up until now it's been difficult to see the complete set of symbols >>> referred to inside a theory, but this can now be displayed with the >>> opentheory info --symbols command (I append the output for the most >>> recent version of the standard theory library: base-1.169). As can be >>> seen, most of the local definitions (which are the symbols in the >>> HOLLight namespace) are abstraction and representation functions for >>> type definitions, but there are also others such as those that are >>> used to construct the real numbers. >>> >>> In my opinion it would make theories more elegant if (some of) these >>> local definitions could be removed, but in the meantime I'd like to >>> know of any instances with clashing local definitions (these could >>> occur either in the same theory or across different theories). My >>> current belief is that these should be easy to fix in a natural way, >>> but I need to see some concrete examples. >>> >>> Cheers, >>> >>> Joe >>> >>> ______________________________________________________ >>> >>> $ opentheory info --symbols base >>> 3 external type operators: -> bool ind >>> 2 external constants: = select >>> 11 defined type operators: Data.List.list Data.Option.option Data.Pair.* >>> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd >>> HOLLight.recspace >>> Number.Natural.natural Number.Real.real Set.set >>> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: >>> Data.List.@ >>> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: >>> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl >>> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval >>> Data.List.last Data.List.length Data.List.map Data.List.member >>> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null >>> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take >>> Data.List.toSet Data.List.zip Data.List.zipWith >>> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome >>> Data.Option.map Data.Option.none Data.Option.some Data.Pair., >>> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right Data.Sum.destLeft >>> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left >>> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip >>> Function.id Function.injective Function.o Function.surjective >>> Function.Combinator.s Function.Combinator.w HOLLight._dest_list >>> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum >>> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec HOLLight._mk_sum >>> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num >>> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add >>> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul >>> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal >>> HOLLight.mk_nadd >>> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add >>> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul >>> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS >>> HOLLight.one_REP >>> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv >>> HOLLight.treal_le >>> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num >>> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS >>> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC >>> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP HOLLight.NUMFST >>> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND >>> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT >>> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ >>> Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> >>> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 >>> Number.Natural.bit1 Number.Natural.distance Number.Natural.div >>> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc >>> Number.Natural.log Number.Natural.max Number.Natural.min >>> Number.Natural.minimal Number.Natural.mod Number.Natural.odd >>> Number.Natural.pre Number.Natural.suc Number.Natural.zero Number.Real.* >>> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< Number.Real.<= >>> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ >>> Number.Real.abs >>> Number.Real.fromNatural Number.Real.inv Number.Real.max Number.Real.min >>> Number.Real.sup Relation.bigIntersect Relation.bigUnion Relation.empty >>> Relation.fromSet Relation.intersect Relation.irreflexive >>> Relation.measure >>> Relation.reflexive Relation.subrelation Relation.toSet >>> Relation.transitive Relation.transitiveClosure Relation.union >>> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect >>> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete >>> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate >>> Set.hasSize Set.image Set.infinite Set.injections Set.insert >>> Set.intersect Set.member Set.properSubset Set.rest Set.singleton >>> Set.size >>> Set.subset Set.surjections Set.union Set.universe >>> >>> _______________________________________________ >>> 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 di.gama at gmail.com Mon Nov 24 22:42:02 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 24 Nov 2014 17:42:02 -0500 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: Hi Joe, On Mon, Nov 24, 2014 at 5:19 PM, Joe Leslie-Hurd wrote: > An example of macro-scopes is the construction of the real numbers, > where you have to develop a big formalization (including definitions) > to construct some mathematical object, and then you throw away that > construction and export a few characteristic properties ("axioms"). > This leaves a bunch of locally defined symbols in the theory (an > example in the standard theory library is the HOLLight.hreal type). > > Cleaning up the micro-scopes is certainly desirable for a theory > package designed to be shared between theorem provers, but I wonder > how much it is possible to clean up the macro-scopes too? It would > involve factoring the construction formalization into theories useful > in their own right, rather than making definitions that are tailored > to the construction of one particular mathematical object. > It may be instructive to see how Metamath does this, since there are no macro-scopes for definitions: all definitions are global. Instead, we use hypotheses that set a variable equal to the object being temporarily defined, then discharge the assumption when we are done with an equality theorem. See http://us2.metamath.org:88/mpegif/omxpen.html for an example of this in action. For an OT example, consider the following sketch of a proof that there is a number greater than 1: The definition way: |- c1 = (1+1) |- 1 < (1+1) |- 1 < c1 |- ?x. 1 < x The temporary definition way: c = (1+1) |- 1 < c <=> 1 < (1+1) |- 1 < (1+1) c = (1+1) |- 1 < c c = (1+1) |- ?x. 1 < x (1+1) = (1+1) |- ?x. 1 < x |- (1+1) = (1+1) |- ?x. 1 < x Basically you carry the term "c = definition" as an antecedent through the proof, where "c" is a free variable, then discharge it when you have derived your goal statement that is independent of the definition. Mario > In the case of the real numbers in HOL Light, one stepping stone is > the construction of the positive real numbers (the "half-real" numbers > represented by the HOLLight.hreal type above), which doesn't sound > particularly useful in its own right, so would fail that test. I > wonder if there is another construction of the real numbers that is > based solely on generally useful mathematical objects? The one I > remember from my undergraduate days makes the type definition > > real = rational set > > where each rational set must be downward-closed (i.e., if a rational > set S contains x then S also contains every rational less than x). > This construction might be more involved than the one in HOL Light, > but has the advantage of being based only on generally useful objects > (sets and rational numbers). > > Cheers, > > Joe > > > On Mon, Nov 24, 2014 at 11:49 AM, Konrad Slind > wrote: > > It's a scoping issue. I think that Peter Homeier's HOL-Omega > > can quantify/bind the local constants used to construct datatypes, > > for example. So its rules may provide guidance on what OpenTheory > > should do. > > > > Sorry, I know I am not answering the original question. > > > > Konrad. > > > > > > On Mon, Nov 24, 2014 at 1:32 PM, Mario Carneiro > wrote: > >> > >> I expect that it will be impossible to remove most of the local > >> definitions that you are talking about, because they serve an important > >> purpose: they are useful for "forgetting" about constructions. Once > you've > >> proven that the reals have the desired properties, it no longer becomes > >> important what sequence of embeddings was used to build the Real type > in the > >> first place, and indeed there is an aesthetic in proofs which avoid any > >> reference to such "construction-dependent" properties. (This process is > made > >> explicit in Metamath, where we derive the basic properties of the reals, > >> then ignore these proofs and replace them with axioms so that you can't > use > >> the construction any more but are forced to use only the properties.) A > >> similar argument applies to the abstraction and representation > functions - > >> unless you are going to be moving between the types often, you may as > well > >> forget about these functions once the basic properties of the new type > are > >> established. > >> > >> These are new constants whose construction is mandated by the language. > >> You can't make a new type without getting abs,rep functions out. You > can't > >> construct a derived type without constructing the base type first. Once > you > >> have the constants, but you no longer need them, what are you supposed > to do > >> with them? > >> > >> Mario > >> > >> On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd > wrote: > >>> > >>> There have been several discussions on this list about symbols (i.e., > >>> type operators and constants) that are defined in a theory but are not > >>> mentioned in any exported theorem, which Rob named local definitions. > >>> Since most of the HOL family of theorem provers maintain a global > >>> symbol table, these local definitions can cause problems if they have > >>> clashing names. > >>> > >>> Up until now it's been difficult to see the complete set of symbols > >>> referred to inside a theory, but this can now be displayed with the > >>> opentheory info --symbols command (I append the output for the most > >>> recent version of the standard theory library: base-1.169). As can be > >>> seen, most of the local definitions (which are the symbols in the > >>> HOLLight namespace) are abstraction and representation functions for > >>> type definitions, but there are also others such as those that are > >>> used to construct the real numbers. > >>> > >>> In my opinion it would make theories more elegant if (some of) these > >>> local definitions could be removed, but in the meantime I'd like to > >>> know of any instances with clashing local definitions (these could > >>> occur either in the same theory or across different theories). My > >>> current belief is that these should be easy to fix in a natural way, > >>> but I need to see some concrete examples. > >>> > >>> Cheers, > >>> > >>> Joe > >>> > >>> ______________________________________________________ > >>> > >>> $ opentheory info --symbols base > >>> 3 external type operators: -> bool ind > >>> 2 external constants: = select > >>> 11 defined type operators: Data.List.list Data.Option.option > Data.Pair.* > >>> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd > >>> HOLLight.recspace > >>> Number.Natural.natural Number.Real.real Set.set > >>> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: > >>> Data.List.@ > >>> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: > >>> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl > >>> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval > >>> Data.List.last Data.List.length Data.List.map Data.List.member > >>> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null > >>> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take > >>> Data.List.toSet Data.List.zip Data.List.zipWith > >>> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome > >>> Data.Option.map Data.Option.none Data.Option.some Data.Pair., > >>> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right > Data.Sum.destLeft > >>> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left > >>> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip > >>> Function.id Function.injective Function.o Function.surjective > >>> Function.Combinator.s Function.Combinator.w HOLLight._dest_list > >>> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum > >>> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec > HOLLight._mk_sum > >>> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num > >>> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add > >>> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul > >>> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal > >>> HOLLight.mk_nadd > >>> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add > >>> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le HOLLight.nadd_mul > >>> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS > >>> HOLLight.one_REP > >>> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv > >>> HOLLight.treal_le > >>> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num > >>> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS > >>> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC > >>> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP > HOLLight.NUMFST > >>> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND > >>> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT > >>> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* Number.Natural.+ > >>> Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> > >>> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 > >>> Number.Natural.bit1 Number.Natural.distance Number.Natural.div > >>> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc > >>> Number.Natural.log Number.Natural.max Number.Natural.min > >>> Number.Natural.minimal Number.Natural.mod Number.Natural.odd > >>> Number.Natural.pre Number.Natural.suc Number.Natural.zero > Number.Real.* > >>> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< > Number.Real.<= > >>> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ > >>> Number.Real.abs > >>> Number.Real.fromNatural Number.Real.inv Number.Real.max > Number.Real.min > >>> Number.Real.sup Relation.bigIntersect Relation.bigUnion > Relation.empty > >>> Relation.fromSet Relation.intersect Relation.irreflexive > >>> Relation.measure > >>> Relation.reflexive Relation.subrelation Relation.toSet > >>> Relation.transitive Relation.transitiveClosure Relation.union > >>> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect > >>> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete > >>> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate > >>> Set.hasSize Set.image Set.infinite Set.injections Set.insert > >>> Set.intersect Set.member Set.properSubset Set.rest Set.singleton > >>> Set.size > >>> Set.subset Set.surjections Set.union Set.universe > >>> > >>> _______________________________________________ > >>> 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.Kumar at cl.cam.ac.uk Tue Nov 25 14:39:39 2014 From: Ramana.Kumar at cl.cam.ac.uk (Ramana Kumar) Date: Tue, 25 Nov 2014 14:39:39 +0000 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: Hi all, I would like to add my voice to this issue, noting that I am a big fan of local definitions (both macro- and micro-scopes, though the former are more important), and I don't think there should be any pressure to remove them from articles. In fact, I see the hiding of local scopes as a great advantage of the semantics of OpenTheory packages. It allows us to implement Bill Farmer's "Little Theories" idea naturally in HOL. I don't think reducing the number of local names should be a weighty factor in deciding how to formalise the reals. Rather, I think article readers and writers should just implement the OpenTheory semantics correctly. Cheers, Ramana On Mon, Nov 24, 2014 at 10:42 PM, Mario Carneiro wrote: > Hi Joe, > > On Mon, Nov 24, 2014 at 5:19 PM, Joe Leslie-Hurd wrote: > >> An example of macro-scopes is the construction of the real numbers, >> where you have to develop a big formalization (including definitions) >> to construct some mathematical object, and then you throw away that >> construction and export a few characteristic properties ("axioms"). >> This leaves a bunch of locally defined symbols in the theory (an >> example in the standard theory library is the HOLLight.hreal type). >> >> Cleaning up the micro-scopes is certainly desirable for a theory >> package designed to be shared between theorem provers, but I wonder >> how much it is possible to clean up the macro-scopes too? It would >> involve factoring the construction formalization into theories useful >> in their own right, rather than making definitions that are tailored >> to the construction of one particular mathematical object. >> > > It may be instructive to see how Metamath does this, since there are no > macro-scopes for definitions: all definitions are global. Instead, we use > hypotheses that set a variable equal to the object being temporarily > defined, then discharge the assumption when we are done with an equality > theorem. See http://us2.metamath.org:88/mpegif/omxpen.html for an example > of this in action. For an OT example, consider the following sketch of a > proof that there is a number greater than 1: > > The definition way: > > |- c1 = (1+1) > |- 1 < (1+1) > |- 1 < c1 > |- ?x. 1 < x > > The temporary definition way: > > c = (1+1) |- 1 < c <=> 1 < (1+1) > |- 1 < (1+1) > c = (1+1) |- 1 < c > c = (1+1) |- ?x. 1 < x > (1+1) = (1+1) |- ?x. 1 < x > |- (1+1) = (1+1) > |- ?x. 1 < x > > Basically you carry the term "c = definition" as an antecedent through the > proof, where "c" is a free variable, then discharge it when you have > derived your goal statement that is independent of the definition. > > Mario > > >> In the case of the real numbers in HOL Light, one stepping stone is >> the construction of the positive real numbers (the "half-real" numbers >> represented by the HOLLight.hreal type above), which doesn't sound >> particularly useful in its own right, so would fail that test. I >> wonder if there is another construction of the real numbers that is >> based solely on generally useful mathematical objects? The one I >> remember from my undergraduate days makes the type definition >> >> real = rational set >> >> where each rational set must be downward-closed (i.e., if a rational >> set S contains x then S also contains every rational less than x). >> This construction might be more involved than the one in HOL Light, >> but has the advantage of being based only on generally useful objects >> (sets and rational numbers). >> >> Cheers, >> >> Joe >> >> >> On Mon, Nov 24, 2014 at 11:49 AM, Konrad Slind >> wrote: >> > It's a scoping issue. I think that Peter Homeier's HOL-Omega >> > can quantify/bind the local constants used to construct datatypes, >> > for example. So its rules may provide guidance on what OpenTheory >> > should do. >> > >> > Sorry, I know I am not answering the original question. >> > >> > Konrad. >> > >> > >> > On Mon, Nov 24, 2014 at 1:32 PM, Mario Carneiro >> wrote: >> >> >> >> I expect that it will be impossible to remove most of the local >> >> definitions that you are talking about, because they serve an important >> >> purpose: they are useful for "forgetting" about constructions. Once >> you've >> >> proven that the reals have the desired properties, it no longer becomes >> >> important what sequence of embeddings was used to build the Real type >> in the >> >> first place, and indeed there is an aesthetic in proofs which avoid any >> >> reference to such "construction-dependent" properties. (This process >> is made >> >> explicit in Metamath, where we derive the basic properties of the >> reals, >> >> then ignore these proofs and replace them with axioms so that you >> can't use >> >> the construction any more but are forced to use only the properties.) A >> >> similar argument applies to the abstraction and representation >> functions - >> >> unless you are going to be moving between the types often, you may as >> well >> >> forget about these functions once the basic properties of the new type >> are >> >> established. >> >> >> >> These are new constants whose construction is mandated by the language. >> >> You can't make a new type without getting abs,rep functions out. You >> can't >> >> construct a derived type without constructing the base type first. >> Once you >> >> have the constants, but you no longer need them, what are you supposed >> to do >> >> with them? >> >> >> >> Mario >> >> >> >> On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd >> wrote: >> >>> >> >>> There have been several discussions on this list about symbols (i.e., >> >>> type operators and constants) that are defined in a theory but are not >> >>> mentioned in any exported theorem, which Rob named local definitions. >> >>> Since most of the HOL family of theorem provers maintain a global >> >>> symbol table, these local definitions can cause problems if they have >> >>> clashing names. >> >>> >> >>> Up until now it's been difficult to see the complete set of symbols >> >>> referred to inside a theory, but this can now be displayed with the >> >>> opentheory info --symbols command (I append the output for the most >> >>> recent version of the standard theory library: base-1.169). As can be >> >>> seen, most of the local definitions (which are the symbols in the >> >>> HOLLight namespace) are abstraction and representation functions for >> >>> type definitions, but there are also others such as those that are >> >>> used to construct the real numbers. >> >>> >> >>> In my opinion it would make theories more elegant if (some of) these >> >>> local definitions could be removed, but in the meantime I'd like to >> >>> know of any instances with clashing local definitions (these could >> >>> occur either in the same theory or across different theories). My >> >>> current belief is that these should be easy to fix in a natural way, >> >>> but I need to see some concrete examples. >> >>> >> >>> Cheers, >> >>> >> >>> Joe >> >>> >> >>> ______________________________________________________ >> >>> >> >>> $ opentheory info --symbols base >> >>> 3 external type operators: -> bool ind >> >>> 2 external constants: = select >> >>> 11 defined type operators: Data.List.list Data.Option.option >> Data.Pair.* >> >>> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd >> >>> HOLLight.recspace >> >>> Number.Natural.natural Number.Real.real Set.set >> >>> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: >> >>> Data.List.@ >> >>> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: >> >>> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl >> >>> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval >> >>> Data.List.last Data.List.length Data.List.map Data.List.member >> >>> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null >> >>> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take >> >>> Data.List.toSet Data.List.zip Data.List.zipWith >> >>> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome >> >>> Data.Option.map Data.Option.none Data.Option.some Data.Pair., >> >>> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right >> Data.Sum.destLeft >> >>> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left >> >>> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip >> >>> Function.id Function.injective Function.o Function.surjective >> >>> Function.Combinator.s Function.Combinator.w HOLLight._dest_list >> >>> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum >> >>> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec >> HOLLight._mk_sum >> >>> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num >> >>> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add >> >>> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul >> >>> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal >> >>> HOLLight.mk_nadd >> >>> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add >> >>> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le >> HOLLight.nadd_mul >> >>> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS >> >>> HOLLight.one_REP >> >>> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv >> >>> HOLLight.treal_le >> >>> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num >> >>> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS >> >>> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC >> >>> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP >> HOLLight.NUMFST >> >>> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND >> >>> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT >> >>> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* >> Number.Natural.+ >> >>> Number.Natural.- Number.Natural.< Number.Natural.<= Number.Natural.> >> >>> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 >> >>> Number.Natural.bit1 Number.Natural.distance Number.Natural.div >> >>> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc >> >>> Number.Natural.log Number.Natural.max Number.Natural.min >> >>> Number.Natural.minimal Number.Natural.mod Number.Natural.odd >> >>> Number.Natural.pre Number.Natural.suc Number.Natural.zero >> Number.Real.* >> >>> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< >> Number.Real.<= >> >>> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ >> >>> Number.Real.abs >> >>> Number.Real.fromNatural Number.Real.inv Number.Real.max >> Number.Real.min >> >>> Number.Real.sup Relation.bigIntersect Relation.bigUnion >> Relation.empty >> >>> Relation.fromSet Relation.intersect Relation.irreflexive >> >>> Relation.measure >> >>> Relation.reflexive Relation.subrelation Relation.toSet >> >>> Relation.transitive Relation.transitiveClosure Relation.union >> >>> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect >> >>> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete >> >>> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate >> >>> Set.hasSize Set.image Set.infinite Set.injections Set.insert >> >>> Set.intersect Set.member Set.properSubset Set.rest Set.singleton >> >>> Set.size >> >>> Set.subset Set.surjections Set.union Set.universe >> >>> >> >>> _______________________________________________ >> >>> 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 Tue Nov 25 16:43:51 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 25 Nov 2014 08:43:51 -0800 Subject: [opentheory-users] Local definitions in theory packages In-Reply-To: References: Message-ID: Hi Ramana, I appreciate the vote of support for theorem provers to support local definitions, and it certainly makes it easier to compose "Little Theories" without worrying about the names of local definitions clashing. However, I just want to clarify that the OpenTheory article spec is deliberately agnostic about the implementation details of definitions. Article readers can ensure soundness using a purely functional logical kernel like the opentheory tool or a global symbol table like the HOL family of theorem provers, and both implementations satisfy the article spec. To support the global symbol table approach I have made two changes to the opentheory tool: 1. Every symbol referred to in a theory can be displayed using the opentheory info --symbols command. 2. The opentheory tool will warn the user when creating an article containing clashing symbols. In addition, I am prepared to change my theories on the public repo if they contain instances of symbols with the same name but different definitions. Cheers, Joe On Tue, Nov 25, 2014 at 6:39 AM, Ramana Kumar wrote: > Hi all, > > I would like to add my voice to this issue, noting that I am a big fan of > local definitions (both macro- and micro-scopes, though the former are more > important), and I don't think there should be any pressure to remove them > from articles. In fact, I see the hiding of local scopes as a great > advantage of the semantics of OpenTheory packages. It allows us to implement > Bill Farmer's "Little Theories" idea naturally in HOL. I don't think > reducing the number of local names should be a weighty factor in deciding > how to formalise the reals. Rather, I think article readers and writers > should just implement the OpenTheory semantics correctly. > > Cheers, > Ramana > > On Mon, Nov 24, 2014 at 10:42 PM, Mario Carneiro wrote: >> >> Hi Joe, >> >> On Mon, Nov 24, 2014 at 5:19 PM, Joe Leslie-Hurd wrote: >>> >>> An example of macro-scopes is the construction of the real numbers, >>> where you have to develop a big formalization (including definitions) >>> to construct some mathematical object, and then you throw away that >>> construction and export a few characteristic properties ("axioms"). >>> This leaves a bunch of locally defined symbols in the theory (an >>> example in the standard theory library is the HOLLight.hreal type). >>> >>> Cleaning up the micro-scopes is certainly desirable for a theory >>> package designed to be shared between theorem provers, but I wonder >>> how much it is possible to clean up the macro-scopes too? It would >>> involve factoring the construction formalization into theories useful >>> in their own right, rather than making definitions that are tailored >>> to the construction of one particular mathematical object. >> >> >> It may be instructive to see how Metamath does this, since there are no >> macro-scopes for definitions: all definitions are global. Instead, we use >> hypotheses that set a variable equal to the object being temporarily >> defined, then discharge the assumption when we are done with an equality >> theorem. See http://us2.metamath.org:88/mpegif/omxpen.html for an example of >> this in action. For an OT example, consider the following sketch of a proof >> that there is a number greater than 1: >> >> The definition way: >> >> |- c1 = (1+1) >> |- 1 < (1+1) >> |- 1 < c1 >> |- ?x. 1 < x >> >> The temporary definition way: >> >> c = (1+1) |- 1 < c <=> 1 < (1+1) >> |- 1 < (1+1) >> c = (1+1) |- 1 < c >> c = (1+1) |- ?x. 1 < x >> (1+1) = (1+1) |- ?x. 1 < x >> |- (1+1) = (1+1) >> |- ?x. 1 < x >> >> Basically you carry the term "c = definition" as an antecedent through the >> proof, where "c" is a free variable, then discharge it when you have derived >> your goal statement that is independent of the definition. >> >> Mario >> >>> >>> In the case of the real numbers in HOL Light, one stepping stone is >>> the construction of the positive real numbers (the "half-real" numbers >>> represented by the HOLLight.hreal type above), which doesn't sound >>> particularly useful in its own right, so would fail that test. I >>> wonder if there is another construction of the real numbers that is >>> based solely on generally useful mathematical objects? The one I >>> remember from my undergraduate days makes the type definition >>> >>> real = rational set >>> >>> where each rational set must be downward-closed (i.e., if a rational >>> set S contains x then S also contains every rational less than x). >>> This construction might be more involved than the one in HOL Light, >>> but has the advantage of being based only on generally useful objects >>> (sets and rational numbers). >>> >>> Cheers, >>> >>> Joe >>> >>> >>> On Mon, Nov 24, 2014 at 11:49 AM, Konrad Slind >>> wrote: >>> > It's a scoping issue. I think that Peter Homeier's HOL-Omega >>> > can quantify/bind the local constants used to construct datatypes, >>> > for example. So its rules may provide guidance on what OpenTheory >>> > should do. >>> > >>> > Sorry, I know I am not answering the original question. >>> > >>> > Konrad. >>> > >>> > >>> > On Mon, Nov 24, 2014 at 1:32 PM, Mario Carneiro >>> > wrote: >>> >> >>> >> I expect that it will be impossible to remove most of the local >>> >> definitions that you are talking about, because they serve an >>> >> important >>> >> purpose: they are useful for "forgetting" about constructions. Once >>> >> you've >>> >> proven that the reals have the desired properties, it no longer >>> >> becomes >>> >> important what sequence of embeddings was used to build the Real type >>> >> in the >>> >> first place, and indeed there is an aesthetic in proofs which avoid >>> >> any >>> >> reference to such "construction-dependent" properties. (This process >>> >> is made >>> >> explicit in Metamath, where we derive the basic properties of the >>> >> reals, >>> >> then ignore these proofs and replace them with axioms so that you >>> >> can't use >>> >> the construction any more but are forced to use only the properties.) >>> >> A >>> >> similar argument applies to the abstraction and representation >>> >> functions - >>> >> unless you are going to be moving between the types often, you may as >>> >> well >>> >> forget about these functions once the basic properties of the new type >>> >> are >>> >> established. >>> >> >>> >> These are new constants whose construction is mandated by the >>> >> language. >>> >> You can't make a new type without getting abs,rep functions out. You >>> >> can't >>> >> construct a derived type without constructing the base type first. >>> >> Once you >>> >> have the constants, but you no longer need them, what are you supposed >>> >> to do >>> >> with them? >>> >> >>> >> Mario >>> >> >>> >> On Mon, Nov 24, 2014 at 2:13 PM, Joe Leslie-Hurd >>> >> wrote: >>> >>> >>> >>> There have been several discussions on this list about symbols (i.e., >>> >>> type operators and constants) that are defined in a theory but are >>> >>> not >>> >>> mentioned in any exported theorem, which Rob named local definitions. >>> >>> Since most of the HOL family of theorem provers maintain a global >>> >>> symbol table, these local definitions can cause problems if they have >>> >>> clashing names. >>> >>> >>> >>> Up until now it's been difficult to see the complete set of symbols >>> >>> referred to inside a theory, but this can now be displayed with the >>> >>> opentheory info --symbols command (I append the output for the most >>> >>> recent version of the standard theory library: base-1.169). As can be >>> >>> seen, most of the local definitions (which are the symbols in the >>> >>> HOLLight namespace) are abstraction and representation functions for >>> >>> type definitions, but there are also others such as those that are >>> >>> used to construct the real numbers. >>> >>> >>> >>> In my opinion it would make theories more elegant if (some of) these >>> >>> local definitions could be removed, but in the meantime I'd like to >>> >>> know of any instances with clashing local definitions (these could >>> >>> occur either in the same theory or across different theories). My >>> >>> current belief is that these should be easy to fix in a natural way, >>> >>> but I need to see some concrete examples. >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Joe >>> >>> >>> >>> ______________________________________________________ >>> >>> >>> >>> $ opentheory info --symbols base >>> >>> 3 external type operators: -> bool ind >>> >>> 2 external constants: = select >>> >>> 11 defined type operators: Data.List.list Data.Option.option >>> >>> Data.Pair.* >>> >>> Data.Sum.+ Data.Unit.unit HOLLight.hreal HOLLight.nadd >>> >>> HOLLight.recspace >>> >>> Number.Natural.natural Number.Real.real Set.set >>> >>> 210 defined constants: ! /\ ==> ? ?! \/ ~ cond F T Data.List.:: >>> >>> Data.List.@ >>> >>> Data.List.[] Data.List.all Data.List.any Data.List.case.[].:: >>> >>> Data.List.concat Data.List.drop Data.List.filter Data.List.foldl >>> >>> Data.List.foldr Data.List.fromSet Data.List.head Data.List.interval >>> >>> Data.List.last Data.List.length Data.List.map Data.List.member >>> >>> Data.List.nth Data.List.nub Data.List.nubReverse Data.List.null >>> >>> Data.List.replicate Data.List.reverse Data.List.tail Data.List.take >>> >>> Data.List.toSet Data.List.zip Data.List.zipWith >>> >>> Data.Option.case.none.some Data.Option.isNone Data.Option.isSome >>> >>> Data.Option.map Data.Option.none Data.Option.some Data.Pair., >>> >>> Data.Pair.fst Data.Pair.snd Data.Sum.case.left.right >>> >>> Data.Sum.destLeft >>> >>> Data.Sum.destRight Data.Sum.isLeft Data.Sum.isRight Data.Sum.left >>> >>> Data.Sum.right Data.Unit.() Function.^ Function.const Function.flip >>> >>> Function.id Function.injective Function.o Function.surjective >>> >>> Function.Combinator.s Function.Combinator.w HOLLight._dest_list >>> >>> HOLLight._dest_option HOLLight._dest_rec HOLLight._dest_sum >>> >>> HOLLight._mk_list HOLLight._mk_option HOLLight._mk_rec >>> >>> HOLLight._mk_sum >>> >>> HOLLight.dest_hreal HOLLight.dest_nadd HOLLight.dest_num >>> >>> HOLLight.dest_real HOLLight.dest_set HOLLight.hreal_add >>> >>> HOLLight.hreal_inv HOLLight.hreal_le HOLLight.hreal_mul >>> >>> HOLLight.hreal_of_num HOLLight.is_nadd HOLLight.mk_hreal >>> >>> HOLLight.mk_nadd >>> >>> HOLLight.mk_num HOLLight.mk_pair HOLLight.mk_real HOLLight.nadd_add >>> >>> HOLLight.nadd_eq HOLLight.nadd_inv HOLLight.nadd_le >>> >>> HOLLight.nadd_mul >>> >>> HOLLight.nadd_of_num HOLLight.nadd_rinv HOLLight.one_ABS >>> >>> HOLLight.one_REP >>> >>> HOLLight.treal_add HOLLight.treal_eq HOLLight.treal_inv >>> >>> HOLLight.treal_le >>> >>> HOLLight.treal_mul HOLLight.treal_neg HOLLight.treal_of_num >>> >>> HOLLight.ABS_prod HOLLight.BOTTOM HOLLight.CONSTR HOLLight.FCONS >>> >>> HOLLight.FINREC HOLLight.FNIL HOLLight.IND_0 HOLLight.IND_SUC >>> >>> HOLLight.INJA HOLLight.INJF HOLLight.INJN HOLLight.INJP >>> >>> HOLLight.NUMFST >>> >>> HOLLight.NUMLEFT HOLLight.NUMPAIR HOLLight.NUMRIGHT HOLLight.NUMSND >>> >>> HOLLight.NUMSUM HOLLight.NUM_REP HOLLight.REP_prod HOLLight.ZBOT >>> >>> HOLLight.ZCONSTR HOLLight.ZRECSPACE Number.Natural.* >>> >>> Number.Natural.+ >>> >>> Number.Natural.- Number.Natural.< Number.Natural.<= >>> >>> Number.Natural.> >>> >>> Number.Natural.>= Number.Natural.^ Number.Natural.bit0 >>> >>> Number.Natural.bit1 Number.Natural.distance Number.Natural.div >>> >>> Number.Natural.even Number.Natural.factorial Number.Natural.isSuc >>> >>> Number.Natural.log Number.Natural.max Number.Natural.min >>> >>> Number.Natural.minimal Number.Natural.mod Number.Natural.odd >>> >>> Number.Natural.pre Number.Natural.suc Number.Natural.zero >>> >>> Number.Real.* >>> >>> Number.Real.+ Number.Real.- Number.Real./ Number.Real.< >>> >>> Number.Real.<= >>> >>> Number.Real.> Number.Real.>= Number.Real.^ Number.Real.~ >>> >>> Number.Real.abs >>> >>> Number.Real.fromNatural Number.Real.inv Number.Real.max >>> >>> Number.Real.min >>> >>> Number.Real.sup Relation.bigIntersect Relation.bigUnion >>> >>> Relation.empty >>> >>> Relation.fromSet Relation.intersect Relation.irreflexive >>> >>> Relation.measure >>> >>> Relation.reflexive Relation.subrelation Relation.toSet >>> >>> Relation.transitive Relation.transitiveClosure Relation.union >>> >>> Relation.universe Relation.wellFounded Set.{} Set.bigIntersect >>> >>> Set.bigUnion Set.bijections Set.choice Set.cross Set.delete >>> >>> Set.difference Set.disjoint Set.finite Set.fold Set.fromPredicate >>> >>> Set.hasSize Set.image Set.infinite Set.injections Set.insert >>> >>> Set.intersect Set.member Set.properSubset Set.rest Set.singleton >>> >>> Set.size >>> >>> Set.subset Set.surjections Set.union Set.universe >>> >>> >>> >>> _______________________________________________ >>> >>> 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 >