From ai.robert.wangshuai at gmail.com Wed Jul 1 20:30:15 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Wed, 1 Jul 2015 22:30:15 +0200 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: Message-ID: Dear Joe, Is there any updates on this? Regards, Robert On 29 June 2015 at 21:04, Robert White wrote: > Dear Joe, > > Thanks for the reply. I am looking forward to the updates! > > Here are things I found which might be useful for you: > > 1) > Looks like there is something wrong going on there in sum.ml: > Exception: Failure "REFL_TAC". > Error in included file ----/hol_light/opentheory/stdlib/sum.ml > > 2) There is no CASES_TAC in the most up-to-date version of HOL Light. > > Questions: > 1) Why do you want things to be different? > > Cheers > Robert > > > > > On 29 June 2015 at 20:30, Joe Leslie-Hurd wrote: > >> Hi Robert, >> >> In general there are quite a few differences in definitions and >> theorems between the OpenTheory fork of HOL Light and the trunk, and >> some of that is here to stay (e.g., the explicit type of sets in the >> OpenTheory fork). >> >> That said, it's past time to do a merge with the HOL Light trunk and >> create a new version of the standard theory library: I will work on >> this. >> >> Cheers, >> >> Joe >> >> >> On Mon, Jun 29, 2015 at 10:43 AM, Robert White >> wrote: >> > Dear Joe, >> > >> > I tried to update the arith.ml file. It seems more complicated than I >> > expected. >> > For example, we have LE_ZERO but the new version deleted it. >> > >> > So shall I continue or maybe you have better advice? >> > Regards, >> > Robert >> > >> > On 29 June 2015 at 19:16, Robert White >> > wrote: >> >> >> >> Dear Joe, >> >> I think HOL Light is more updated. We maybe need to export some files >> >> again. >> >> For example. the arith.ml >> >> The first missing thm is ADD_SUBR, while in the up-to-date HOL Light >> they >> >> have ADD_SUBR defined but not in OpenTheory HOL. >> >> So I have the feeling that we need to generate the base.art again I >> think? >> >> >> >> Regards, >> >> Robert >> >> >> >> >> >> On 26 June 2015 at 06:44, Joe Leslie-Hurd wrote: >> >>> >> >>> Hi Robert, >> >>> >> >>> This is a mystery to me: perhaps there are many theorems deleted in >> >>> the OpenTheory fork of HOL Light compared to the standard distribution >> >>> (which is what the database.ml file records)? >> >>> >> >>> Cheers, >> >>> >> >>> Joe >> >>> >> >>> >> >>> On Thu, Jun 25, 2015 at 3:26 AM, Robert White >> >>> wrote: >> >>> > Hi again. >> >>> > >> >>> > There are over 2200 thms in the hol database.ml but there are "to >> the >> >>> > most"[1] 1885 thms. So where are the rest? >> >>> > >> >>> > [1]I tried to load the files commented out in hol.ml. >> >>> > >> >>> > >> >>> > On 25 June 2015 at 12:16, Robert White < >> ai.robert.wangshuai at gmail.com> >> >>> > wrote: >> >>> >> >> >>> >> Hi Joe, >> >>> >> >> >>> >> So I tested the HOL "theorems" also, Here are the results: >> >>> >> # List.length(!theorems);; >> >>> >> val it : int = 1670 >> >>> >> >> >>> >> So that means there are 1670 - 1214 = 456 theorems not exported to >> >>> >> Opentheory? >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> On 25 June 2015 at 12:06, Robert White < >> ai.robert.wangshuai at gmail.com> >> >>> >> wrote: >> >>> >>> >> >>> >>> Hi Joe, >> >>> >>> >> >>> >>> Thanks for the reply. >> >>> >>> >> >>> >>> 2) So maybe I can try to export them? Cos the more thms I get is >> >>> >>> better >> >>> >>> for my tests. >> >>> >>> but I got more thms when I do this search. Why is that (So far we >> >>> >>> should >> >>> >>> have 1214 right? 1214 are those only exported but 1670 are all of >> >>> >>> them (so >> >>> >>> far))? >> >>> >>> >> >>> >>> # List.length (search []) >> >>> >>> ;; >> >>> >>> val it : int = 1670 >> >>> >>> >> >>> >>> >> >>> >>> On 24 June 2015 at 23:11, Joe Leslie-Hurd wrote: >> >>> >>>> >> >>> >>>> Hi Robert, >> >>> >>>> >> >>> >>>> Welcome back! >> >>> >>>> >> >>> >>>> 1) There hasn't been much development on OpenTheory in recent >> weeks, >> >>> >>>> just some extensions to the natural-divides theory to support my >> >>> >>>> recent blog post on the extended GCD algorithm: >> >>> >>>> >> >>> >>>> >> >>> >>>> >> >>> >>>> >> https://gilith.wordpress.com/2015/06/24/natural-number-greatest-common-divisor/ >> >>> >>>> >> >>> >>>> 2) There is no real reason why those HOL Light theories have not >> >>> >>>> been >> >>> >>>> ported to OpenTheory, except that some of them might not be >> needed >> >>> >>>> to >> >>> >>>> compile a standard theory library (which is a common base of >> >>> >>>> theories >> >>> >>>> that is expected to be implemented in every theorem prover). >> >>> >>>> >> >>> >>>> We do not use the database.ml file which lists all the theorems >> in >> >>> >>>> the >> >>> >>>> main branch of the HOL Light theorem prover (not the OpenTheory >> >>> >>>> fork). >> >>> >>>> But I've just checked in a version of the fork that creates a >> >>> >>>> theorem >> >>> >>>> database of the standard theory library at the bottom of the >> hol.ml >> >>> >>>> file, so after loading with #use "hol.ml";; you can search the >> >>> >>>> database like so: >> >>> >>>> >> >>> >>>> # search [`MAX (SUC m) (SUC n)`];; >> >>> >>>> val it : (string * thm) list = >> >>> >>>> [("MAX_SUC", |- !m n. MAX (SUC m) (SUC n) = SUC (MAX m n))] >> >>> >>>> >> >>> >>>> 3) It looks like you need to extend_the_interpretation before >> >>> >>>> loading >> >>> >>>> the proofs as described in >> >>> >>>> >> >>> >>>> >> >>> >>>> >> http://www.gilith.com/pipermail/opentheory-users/2015-June/000515.html >> >>> >>>> >> >>> >>>> Cheers, >> >>> >>>> >> >>> >>>> Joe >> >>> >>>> >> >>> >>>> On Wed, Jun 24, 2015 at 1:31 PM, Robert White >> >>> >>>> wrote: >> >>> >>>> > Dear Joe and all, >> >>> >>>> > >> >>> >>>> > I am back to the community! >> >>> >>>> > >> >>> >>>> > I have the following questions and updates for you: >> >>> >>>> > >> >>> >>>> > 1) I will be finishing my internship in a few weeks and it >> would >> >>> >>>> > be >> >>> >>>> > nice of >> >>> >>>> > you if you can give me some description of the most recent >> updates >> >>> >>>> > of >> >>> >>>> > OpenTheory. >> >>> >>>> > >> >>> >>>> > 2) >> >>> >>>> > I noticed there is a part not imported to Opentheory (in >> hol.ml) : >> >>> >>>> > >> >>> >>>> > (* Not yet ported to OpenTheory >> >>> >>>> > loads "calc_int.ml";; (* Calculation with integer-valued >> reals >> >>> >>>> > *) >> >>> >>>> > loads "realarith.ml";; (* Universal linear real decision >> >>> >>>> > procedure >> >>> >>>> > *) >> >>> >>>> > loads "real.ml";; (* Derived properties of reals >> >>> >>>> > *) >> >>> >>>> > loads "calc_rat.ml";; (* Calculation with rational-valued >> reals >> >>> >>>> > *) >> >>> >>>> > loads "int.ml";; (* Definition of integers >> >>> >>>> > *) >> >>> >>>> > loads "iterate.ml";; (* Iterated operations >> >>> >>>> > *) >> >>> >>>> > loads "cart.ml";; (* Finite Cartesian products >> >>> >>>> > *) >> >>> >>>> > *) >> >>> >>>> > >> >>> >>>> > Is there any reason why not? >> >>> >>>> > >> >>> >>>> > Also, there is a database.ml file. Shall I ignore that in >> >>> >>>> > OpenTheory >> >>> >>>> > HOL? >> >>> >>>> > (since it is not complete anyway) >> >>> >>>> > >> >>> >>>> > 3) >> >>> >>>> > I have problem loading article files: >> >>> >>>> > >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/stream.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article >> /home/robert/Project/laholide/opentheory/stream.art >> >>> >>>> > at >> >>> >>>> > line >> >>> >>>> > 1273: defineTypeOp\nstack = [Thm; [\"A\"]; \"Data.Stream.nth\"; >> >>> >>>> > \"Data.Stream.fromFunction\"; \"Data.Stream.stream\"; Var; Var; >> >>> >>>> > \"Data.Stream.unfold\"; Var; \"Data.Stream.iterate\"; >> >>> >>>> > \"Data.Stream.replicate\"]\nunknown type operator >> >>> >>>> > \"Data.Stream.stream\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-prime.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article >> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-prime.art at >> >>> >>>> > line 191: const\nstack = [\"Number.Natural.divides\"; Term; >> Var; >> >>> >>>> > Term; >> >>> >>>> > Term; >> >>> >>>> > Var; \"Number.Natural.prime\"; Term; Var; [[]; [[Var; Term]]]; >> >>> >>>> > Thm]\nunknown >> >>> >>>> > constant \"Number.Natural.divides\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art";; >> >>> >>>> > Exception: >> >>> >>>> > Sys_error >> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art: >> No >> >>> >>>> > such >> >>> >>>> > file >> >>> >>>> > or directory". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > >> "/home/robert/Project/laholide/opentheory/natural-divides.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article >> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-divides.art at >> >>> >>>> > line 159: defineConst\nstack = [Term; >> \"Number.Natural.divides\"; >> >>> >>>> > Var; >> >>> >>>> > Var; >> >>> >>>> > []]\nunknown constant \"Number.Natural.divides\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/modular.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article >> /home/robert/Project/laholide/opentheory/modular.art >> >>> >>>> > at >> >>> >>>> > line >> >>> >>>> > 155: const\nstack = [\"Number.Modular.modulus\"; Term; Term; >> Var; >> >>> >>>> > Var; >> >>> >>>> > \"Number.Modular.equivalent\"; Term; Var; Term; Var; []; >> >>> >>>> > \"HOLLight.modular_to_class\"; \"HOLLight.modular_from_class\"; >> >>> >>>> > \"Number.Modular.modular\"; TypeOp; TypeOp; >> >>> >>>> > Const]\nunknown >> >>> >>>> > constant \"Number.Modular.modulus\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/gfp.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article /home/robert/Project/laholide/opentheory/gfp.art >> at >> >>> >>>> > line >> >>> >>>> > 54: >> >>> >>>> > const\nstack = [\"Number.GF(p).oddprime\"; Term; Var; >> []]\nunknown >> >>> >>>> > constant >> >>> >>>> > \"Number.GF(p).oddprime\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > >> "/home/robert/Project/laholide/opentheory/natural-fibonacci.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article >> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-fibonacci.art >> >>> >>>> > at line 1933: defineConstList\nstack = [Thm; >> >>> >>>> > [[\"Number.Natural.Fibonacci.zeckendorf\"; Var]]; Var; []; >> >>> >>>> > Thm]\nunknown >> >>> >>>> > constant \"Number.Natural.Fibonacci.zeckendorf\"". >> >>> >>>> > # let p = load_proofs >> >>> >>>> > "/home/robert/Project/laholide/opentheory/word.art";; >> >>> >>>> > Exception: >> >>> >>>> > Failure >> >>> >>>> > "in article /home/robert/Project/laholide/opentheory/word.art >> at >> >>> >>>> > line >> >>> >>>> > 130: >> >>> >>>> > const\nstack = [\"Data.Word.width\"; Term; >> \"Data.Word.modulus\"; >> >>> >>>> > Thm; >> >>> >>>> > Thm]\nunknown constant \"Data.Word.width\"". >> >>> >>>> > # >> >>> >>>> > >> >>> >>>> > Could you please help on that? It seems I can't even play with >> the >> >>> >>>> > other >> >>> >>>> > article files I used to be able to load either :( >> >>> >>>> > >> >>> >>>> > Thanks very much! >> >>> >>>> > >> >>> >>>> > -- >> >>> >>>> > >> >>> >>>> > Regards, >> >>> >>>> > Robert White (Shuai Wang) >> >>> >>>> > INRIA Deducteam >> >>> >>>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >>>> > [New email address will be shuai.wang at student.uva.nl] >> >>> >>>> > >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> -- >> >>> >>> >> >>> >>> Regards, >> >>> >>> Robert White (Shuai Wang) >> >>> >>> INRIA Deducteam >> >>> >>> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >>> [New email address will be shuai.wang at student.uva.nl] >> >>> >>> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> Regards, >> >>> >> Robert White (Shuai Wang) >> >>> >> INRIA Deducteam >> >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >> [New email address will be shuai.wang at student.uva.nl] >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > >> >>> > Regards, >> >>> > Robert White (Shuai Wang) >> >>> > INRIA Deducteam >> >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> > [New email address will be shuai.wang at student.uva.nl] >> >>> > >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Regards, >> >> Robert White (Shuai Wang) >> >> INRIA Deducteam >> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >> [New email address will be shuai.wang at student.uva.nl] >> >> >> > >> > >> > >> > -- >> > >> > Regards, >> > Robert White (Shuai Wang) >> > INRIA Deducteam >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> > [New email address will be shuai.wang at student.uva.nl] >> > >> > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > > -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Wed Jul 1 20:57:31 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 1 Jul 2015 13:57:31 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: Message-ID: Hi Robert, Sorry, I haven't been able to do the merge yet (it's a bit fiddly, so it requires an uninterrupted block of time which is a scarce resource for me right now). However, I can answer your question right now. I do want the OpenTheory fork of HOL Light to be as close as possible to the main trunk of HOL Light, but there are certain changes that are required to export a standard theory library (which is the primary purpose of this fork). For example, introducing an explicit set type (A set) rather than the predicate (A -> bool) and removing default cases (e.g., PRE 0 = 0) are necessary to ensure the standard theory library can be used in as many environments as possible. Cheers, Joe On Wed, Jul 1, 2015 at 1:30 PM, Robert White wrote: > Dear Joe, > > Is there any updates on this? > > Regards, > Robert > > On 29 June 2015 at 21:04, Robert White > wrote: >> >> Dear Joe, >> >> Thanks for the reply. I am looking forward to the updates! >> >> Here are things I found which might be useful for you: >> >> 1) >> Looks like there is something wrong going on there in sum.ml: >> Exception: Failure "REFL_TAC". >> Error in included file ----/hol_light/opentheory/stdlib/sum.ml >> >> 2) There is no CASES_TAC in the most up-to-date version of HOL Light. >> >> Questions: >> 1) Why do you want things to be different? >> >> Cheers >> Robert >> >> >> >> >> On 29 June 2015 at 20:30, Joe Leslie-Hurd wrote: >>> >>> Hi Robert, >>> >>> In general there are quite a few differences in definitions and >>> theorems between the OpenTheory fork of HOL Light and the trunk, and >>> some of that is here to stay (e.g., the explicit type of sets in the >>> OpenTheory fork). >>> >>> That said, it's past time to do a merge with the HOL Light trunk and >>> create a new version of the standard theory library: I will work on >>> this. >>> >>> Cheers, >>> >>> Joe >>> >>> >>> On Mon, Jun 29, 2015 at 10:43 AM, Robert White >>> wrote: >>> > Dear Joe, >>> > >>> > I tried to update the arith.ml file. It seems more complicated than I >>> > expected. >>> > For example, we have LE_ZERO but the new version deleted it. >>> > >>> > So shall I continue or maybe you have better advice? >>> > Regards, >>> > Robert >>> > >>> > On 29 June 2015 at 19:16, Robert White >>> > wrote: >>> >> >>> >> Dear Joe, >>> >> I think HOL Light is more updated. We maybe need to export some files >>> >> again. >>> >> For example. the arith.ml >>> >> The first missing thm is ADD_SUBR, while in the up-to-date HOL Light >>> >> they >>> >> have ADD_SUBR defined but not in OpenTheory HOL. >>> >> So I have the feeling that we need to generate the base.art again I >>> >> think? >>> >> >>> >> Regards, >>> >> Robert >>> >> >>> >> >>> >> On 26 June 2015 at 06:44, Joe Leslie-Hurd wrote: >>> >>> >>> >>> Hi Robert, >>> >>> >>> >>> This is a mystery to me: perhaps there are many theorems deleted in >>> >>> the OpenTheory fork of HOL Light compared to the standard >>> >>> distribution >>> >>> (which is what the database.ml file records)? >>> >>> >>> >>> Cheers, >>> >>> >>> >>> Joe >>> >>> >>> >>> >>> >>> On Thu, Jun 25, 2015 at 3:26 AM, Robert White >>> >>> wrote: >>> >>> > Hi again. >>> >>> > >>> >>> > There are over 2200 thms in the hol database.ml but there are "to >>> >>> > the >>> >>> > most"[1] 1885 thms. So where are the rest? >>> >>> > >>> >>> > [1]I tried to load the files commented out in hol.ml. >>> >>> > >>> >>> > >>> >>> > On 25 June 2015 at 12:16, Robert White >>> >>> > >>> >>> > wrote: >>> >>> >> >>> >>> >> Hi Joe, >>> >>> >> >>> >>> >> So I tested the HOL "theorems" also, Here are the results: >>> >>> >> # List.length(!theorems);; >>> >>> >> val it : int = 1670 >>> >>> >> >>> >>> >> So that means there are 1670 - 1214 = 456 theorems not exported to >>> >>> >> Opentheory? >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> On 25 June 2015 at 12:06, Robert White >>> >>> >> >>> >>> >> wrote: >>> >>> >>> >>> >>> >>> Hi Joe, >>> >>> >>> >>> >>> >>> Thanks for the reply. >>> >>> >>> >>> >>> >>> 2) So maybe I can try to export them? Cos the more thms I get is >>> >>> >>> better >>> >>> >>> for my tests. >>> >>> >>> but I got more thms when I do this search. Why is that (So far we >>> >>> >>> should >>> >>> >>> have 1214 right? 1214 are those only exported but 1670 are all of >>> >>> >>> them (so >>> >>> >>> far))? >>> >>> >>> >>> >>> >>> # List.length (search []) >>> >>> >>> ;; >>> >>> >>> val it : int = 1670 >>> >>> >>> >>> >>> >>> >>> >>> >>> On 24 June 2015 at 23:11, Joe Leslie-Hurd wrote: >>> >>> >>>> >>> >>> >>>> Hi Robert, >>> >>> >>>> >>> >>> >>>> Welcome back! >>> >>> >>>> >>> >>> >>>> 1) There hasn't been much development on OpenTheory in recent >>> >>> >>>> weeks, >>> >>> >>>> just some extensions to the natural-divides theory to support my >>> >>> >>>> recent blog post on the extended GCD algorithm: >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> https://gilith.wordpress.com/2015/06/24/natural-number-greatest-common-divisor/ >>> >>> >>>> >>> >>> >>>> 2) There is no real reason why those HOL Light theories have not >>> >>> >>>> been >>> >>> >>>> ported to OpenTheory, except that some of them might not be >>> >>> >>>> needed >>> >>> >>>> to >>> >>> >>>> compile a standard theory library (which is a common base of >>> >>> >>>> theories >>> >>> >>>> that is expected to be implemented in every theorem prover). >>> >>> >>>> >>> >>> >>>> We do not use the database.ml file which lists all the theorems >>> >>> >>>> in >>> >>> >>>> the >>> >>> >>>> main branch of the HOL Light theorem prover (not the OpenTheory >>> >>> >>>> fork). >>> >>> >>>> But I've just checked in a version of the fork that creates a >>> >>> >>>> theorem >>> >>> >>>> database of the standard theory library at the bottom of the >>> >>> >>>> hol.ml >>> >>> >>>> file, so after loading with #use "hol.ml";; you can search the >>> >>> >>>> database like so: >>> >>> >>>> >>> >>> >>>> # search [`MAX (SUC m) (SUC n)`];; >>> >>> >>>> val it : (string * thm) list = >>> >>> >>>> [("MAX_SUC", |- !m n. MAX (SUC m) (SUC n) = SUC (MAX m n))] >>> >>> >>>> >>> >>> >>>> 3) It looks like you need to extend_the_interpretation before >>> >>> >>>> loading >>> >>> >>>> the proofs as described in >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> >>> >>> >>>> http://www.gilith.com/pipermail/opentheory-users/2015-June/000515.html >>> >>> >>>> >>> >>> >>>> Cheers, >>> >>> >>>> >>> >>> >>>> Joe >>> >>> >>>> >>> >>> >>>> On Wed, Jun 24, 2015 at 1:31 PM, Robert White >>> >>> >>>> wrote: >>> >>> >>>> > Dear Joe and all, >>> >>> >>>> > >>> >>> >>>> > I am back to the community! >>> >>> >>>> > >>> >>> >>>> > I have the following questions and updates for you: >>> >>> >>>> > >>> >>> >>>> > 1) I will be finishing my internship in a few weeks and it >>> >>> >>>> > would >>> >>> >>>> > be >>> >>> >>>> > nice of >>> >>> >>>> > you if you can give me some description of the most recent >>> >>> >>>> > updates >>> >>> >>>> > of >>> >>> >>>> > OpenTheory. >>> >>> >>>> > >>> >>> >>>> > 2) >>> >>> >>>> > I noticed there is a part not imported to Opentheory (in >>> >>> >>>> > hol.ml) : >>> >>> >>>> > >>> >>> >>>> > (* Not yet ported to OpenTheory >>> >>> >>>> > loads "calc_int.ml";; (* Calculation with integer-valued >>> >>> >>>> > reals >>> >>> >>>> > *) >>> >>> >>>> > loads "realarith.ml";; (* Universal linear real decision >>> >>> >>>> > procedure >>> >>> >>>> > *) >>> >>> >>>> > loads "real.ml";; (* Derived properties of reals >>> >>> >>>> > *) >>> >>> >>>> > loads "calc_rat.ml";; (* Calculation with rational-valued >>> >>> >>>> > reals >>> >>> >>>> > *) >>> >>> >>>> > loads "int.ml";; (* Definition of integers >>> >>> >>>> > *) >>> >>> >>>> > loads "iterate.ml";; (* Iterated operations >>> >>> >>>> > *) >>> >>> >>>> > loads "cart.ml";; (* Finite Cartesian products >>> >>> >>>> > *) >>> >>> >>>> > *) >>> >>> >>>> > >>> >>> >>>> > Is there any reason why not? >>> >>> >>>> > >>> >>> >>>> > Also, there is a database.ml file. Shall I ignore that in >>> >>> >>>> > OpenTheory >>> >>> >>>> > HOL? >>> >>> >>>> > (since it is not complete anyway) >>> >>> >>>> > >>> >>> >>>> > 3) >>> >>> >>>> > I have problem loading article files: >>> >>> >>>> > >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/stream.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article >>> >>> >>>> > /home/robert/Project/laholide/opentheory/stream.art >>> >>> >>>> > at >>> >>> >>>> > line >>> >>> >>>> > 1273: defineTypeOp\nstack = [Thm; [\"A\"]; >>> >>> >>>> > \"Data.Stream.nth\"; >>> >>> >>>> > \"Data.Stream.fromFunction\"; \"Data.Stream.stream\"; Var; >>> >>> >>>> > Var; >>> >>> >>>> > \"Data.Stream.unfold\"; Var; \"Data.Stream.iterate\"; >>> >>> >>>> > \"Data.Stream.replicate\"]\nunknown type operator >>> >>> >>>> > \"Data.Stream.stream\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-prime.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-prime.art at >>> >>> >>>> > line 191: const\nstack = [\"Number.Natural.divides\"; Term; >>> >>> >>>> > Var; >>> >>> >>>> > Term; >>> >>> >>>> > Term; >>> >>> >>>> > Var; \"Number.Natural.prime\"; Term; Var; [[]; [[Var; Term]]]; >>> >>> >>>> > Thm]\nunknown >>> >>> >>>> > constant \"Number.Natural.divides\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Sys_error >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art: >>> >>> >>>> > No >>> >>> >>>> > such >>> >>> >>>> > file >>> >>> >>>> > or directory". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divides.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-divides.art >>> >>> >>>> > at >>> >>> >>>> > line 159: defineConst\nstack = [Term; >>> >>> >>>> > \"Number.Natural.divides\"; >>> >>> >>>> > Var; >>> >>> >>>> > Var; >>> >>> >>>> > []]\nunknown constant \"Number.Natural.divides\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/modular.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article >>> >>> >>>> > /home/robert/Project/laholide/opentheory/modular.art >>> >>> >>>> > at >>> >>> >>>> > line >>> >>> >>>> > 155: const\nstack = [\"Number.Modular.modulus\"; Term; Term; >>> >>> >>>> > Var; >>> >>> >>>> > Var; >>> >>> >>>> > \"Number.Modular.equivalent\"; Term; Var; Term; Var; []; >>> >>> >>>> > \"HOLLight.modular_to_class\"; >>> >>> >>>> > \"HOLLight.modular_from_class\"; >>> >>> >>>> > \"Number.Modular.modular\"; TypeOp; TypeOp; >>> >>> >>>> > Const]\nunknown >>> >>> >>>> > constant \"Number.Modular.modulus\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/gfp.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article /home/robert/Project/laholide/opentheory/gfp.art >>> >>> >>>> > at >>> >>> >>>> > line >>> >>> >>>> > 54: >>> >>> >>>> > const\nstack = [\"Number.GF(p).oddprime\"; Term; Var; >>> >>> >>>> > []]\nunknown >>> >>> >>>> > constant >>> >>> >>>> > \"Number.GF(p).oddprime\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-fibonacci.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-fibonacci.art >>> >>> >>>> > at line 1933: defineConstList\nstack = [Thm; >>> >>> >>>> > [[\"Number.Natural.Fibonacci.zeckendorf\"; Var]]; Var; []; >>> >>> >>>> > Thm]\nunknown >>> >>> >>>> > constant \"Number.Natural.Fibonacci.zeckendorf\"". >>> >>> >>>> > # let p = load_proofs >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/word.art";; >>> >>> >>>> > Exception: >>> >>> >>>> > Failure >>> >>> >>>> > "in article /home/robert/Project/laholide/opentheory/word.art >>> >>> >>>> > at >>> >>> >>>> > line >>> >>> >>>> > 130: >>> >>> >>>> > const\nstack = [\"Data.Word.width\"; Term; >>> >>> >>>> > \"Data.Word.modulus\"; >>> >>> >>>> > Thm; >>> >>> >>>> > Thm]\nunknown constant \"Data.Word.width\"". >>> >>> >>>> > # >>> >>> >>>> > >>> >>> >>>> > Could you please help on that? It seems I can't even play with >>> >>> >>>> > the >>> >>> >>>> > other >>> >>> >>>> > article files I used to be able to load either :( >>> >>> >>>> > >>> >>> >>>> > Thanks very much! >>> >>> >>>> > >>> >>> >>>> > -- >>> >>> >>>> > >>> >>> >>>> > Regards, >>> >>> >>>> > Robert White (Shuai Wang) >>> >>> >>>> > INRIA Deducteam >>> >>> >>>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >>> >>>> > [New email address will be shuai.wang at student.uva.nl] >>> >>> >>>> > >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> -- >>> >>> >>> >>> >>> >>> Regards, >>> >>> >>> Robert White (Shuai Wang) >>> >>> >>> INRIA Deducteam >>> >>> >>> [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >>> >>> [New email address will be shuai.wang at student.uva.nl] >>> >>> >>> >>> >>> >> >>> >>> >> >>> >>> >> >>> >>> >> -- >>> >>> >> >>> >>> >> Regards, >>> >>> >> Robert White (Shuai Wang) >>> >>> >> INRIA Deducteam >>> >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >>> >> [New email address will be shuai.wang at student.uva.nl] >>> >>> >> >>> >>> > >>> >>> > >>> >>> > >>> >>> > -- >>> >>> > >>> >>> > Regards, >>> >>> > Robert White (Shuai Wang) >>> >>> > INRIA Deducteam >>> >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >>> > [New email address will be shuai.wang at student.uva.nl] >>> >>> > >>> >> >>> >> >>> >> >>> >> >>> >> -- >>> >> >>> >> Regards, >>> >> Robert White (Shuai Wang) >>> >> INRIA Deducteam >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >> [New email address will be shuai.wang at student.uva.nl] >>> >> >>> > >>> > >>> > >>> > -- >>> > >>> > Regards, >>> > Robert White (Shuai Wang) >>> > INRIA Deducteam >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> > [New email address will be shuai.wang at student.uva.nl] >>> > >> >> >> >> >> -- >> >> Regards, >> Robert White (Shuai Wang) >> INRIA Deducteam >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> [New email address will be shuai.wang at student.uva.nl] >> > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > From Michael.Norrish at nicta.com.au Thu Jul 2 05:38:23 2015 From: Michael.Norrish at nicta.com.au (Michael Norrish) Date: Thu, 2 Jul 2015 05:38:23 +0000 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: Message-ID: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> > On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: > However, I can answer your question right now. I do want the > OpenTheory fork of HOL Light to be as close as possible to the main > trunk of HOL Light, but there are certain changes that are required to > export a standard theory library (which is the primary purpose of this > fork). For example, introducing an explicit set type (A set) rather > than the predicate (A -> bool) and removing default cases (e.g., PRE 0 > = 0) are necessary to ensure the standard theory library can be used > in as many environments as possible. Is it not now our experience that providing an explicit set type actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? Michael ________________________________ The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. From joe at gilith.com Thu Jul 2 15:58:32 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 2 Jul 2015 08:58:32 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: Hi Michael, I think your statement is correct, because both HOL Light and HOL4 use predicates rather than an explicit set type, so if OpenTheory also used predicates it would simplify translation between these two environments. And indeed, it complicates export if an explicit set type has to be reconstructed from predicates. However, one design principle of OpenTheory is that whenever there is a trade-off between simplifying import or export then it's better to simplify importing, and in this case it's easy to drop the explicit set type in favour of predicates during import. And there are other environments that do implement explicit set types, such as Haskell. When exporting theories as Haskell packages I want to export explicit sets as Haskell sets, which would be difficult if OpenTheory used predicates. Cheers, Joe On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish wrote: > >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: > >> However, I can answer your question right now. I do want the >> OpenTheory fork of HOL Light to be as close as possible to the main >> trunk of HOL Light, but there are certain changes that are required to >> export a standard theory library (which is the primary purpose of this >> fork). For example, introducing an explicit set type (A set) rather >> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 >> = 0) are necessary to ensure the standard theory library can be used >> in as many environments as possible. > > Is it not now our experience that providing an explicit set type actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? > > Michael > > ________________________________ > > The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users From ai.robert.wangshuai at gmail.com Wed Jul 1 22:09:39 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Thu, 2 Jul 2015 00:09:39 +0200 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: Message-ID: Okay then. Looks like I have to use the old data for testing then. Please let me know when it's updated :) Thanks a lot Robert On 1 July 2015 at 22:57, Joe Leslie-Hurd wrote: > Hi Robert, > > Sorry, I haven't been able to do the merge yet (it's a bit fiddly, so > it requires an uninterrupted block of time which is a scarce resource > for me right now). > > However, I can answer your question right now. I do want the > OpenTheory fork of HOL Light to be as close as possible to the main > trunk of HOL Light, but there are certain changes that are required to > export a standard theory library (which is the primary purpose of this > fork). For example, introducing an explicit set type (A set) rather > than the predicate (A -> bool) and removing default cases (e.g., PRE 0 > = 0) are necessary to ensure the standard theory library can be used > in as many environments as possible. > > Cheers, > > Joe > > > > On Wed, Jul 1, 2015 at 1:30 PM, Robert White > wrote: > > Dear Joe, > > > > Is there any updates on this? > > > > Regards, > > Robert > > > > On 29 June 2015 at 21:04, Robert White > > wrote: > >> > >> Dear Joe, > >> > >> Thanks for the reply. I am looking forward to the updates! > >> > >> Here are things I found which might be useful for you: > >> > >> 1) > >> Looks like there is something wrong going on there in sum.ml: > >> Exception: Failure "REFL_TAC". > >> Error in included file ----/hol_light/opentheory/stdlib/sum.ml > >> > >> 2) There is no CASES_TAC in the most up-to-date version of HOL Light. > >> > >> Questions: > >> 1) Why do you want things to be different? > >> > >> Cheers > >> Robert > >> > >> > >> > >> > >> On 29 June 2015 at 20:30, Joe Leslie-Hurd wrote: > >>> > >>> Hi Robert, > >>> > >>> In general there are quite a few differences in definitions and > >>> theorems between the OpenTheory fork of HOL Light and the trunk, and > >>> some of that is here to stay (e.g., the explicit type of sets in the > >>> OpenTheory fork). > >>> > >>> That said, it's past time to do a merge with the HOL Light trunk and > >>> create a new version of the standard theory library: I will work on > >>> this. > >>> > >>> Cheers, > >>> > >>> Joe > >>> > >>> > >>> On Mon, Jun 29, 2015 at 10:43 AM, Robert White > >>> wrote: > >>> > Dear Joe, > >>> > > >>> > I tried to update the arith.ml file. It seems more complicated than > I > >>> > expected. > >>> > For example, we have LE_ZERO but the new version deleted it. > >>> > > >>> > So shall I continue or maybe you have better advice? > >>> > Regards, > >>> > Robert > >>> > > >>> > On 29 June 2015 at 19:16, Robert White < > ai.robert.wangshuai at gmail.com> > >>> > wrote: > >>> >> > >>> >> Dear Joe, > >>> >> I think HOL Light is more updated. We maybe need to export some > files > >>> >> again. > >>> >> For example. the arith.ml > >>> >> The first missing thm is ADD_SUBR, while in the up-to-date HOL Light > >>> >> they > >>> >> have ADD_SUBR defined but not in OpenTheory HOL. > >>> >> So I have the feeling that we need to generate the base.art again I > >>> >> think? > >>> >> > >>> >> Regards, > >>> >> Robert > >>> >> > >>> >> > >>> >> On 26 June 2015 at 06:44, Joe Leslie-Hurd wrote: > >>> >>> > >>> >>> Hi Robert, > >>> >>> > >>> >>> This is a mystery to me: perhaps there are many theorems deleted in > >>> >>> the OpenTheory fork of HOL Light compared to the standard > >>> >>> distribution > >>> >>> (which is what the database.ml file records)? > >>> >>> > >>> >>> Cheers, > >>> >>> > >>> >>> Joe > >>> >>> > >>> >>> > >>> >>> On Thu, Jun 25, 2015 at 3:26 AM, Robert White > >>> >>> wrote: > >>> >>> > Hi again. > >>> >>> > > >>> >>> > There are over 2200 thms in the hol database.ml but there are > "to > >>> >>> > the > >>> >>> > most"[1] 1885 thms. So where are the rest? > >>> >>> > > >>> >>> > [1]I tried to load the files commented out in hol.ml. > >>> >>> > > >>> >>> > > >>> >>> > On 25 June 2015 at 12:16, Robert White > >>> >>> > > >>> >>> > wrote: > >>> >>> >> > >>> >>> >> Hi Joe, > >>> >>> >> > >>> >>> >> So I tested the HOL "theorems" also, Here are the results: > >>> >>> >> # List.length(!theorems);; > >>> >>> >> val it : int = 1670 > >>> >>> >> > >>> >>> >> So that means there are 1670 - 1214 = 456 theorems not exported > to > >>> >>> >> Opentheory? > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> On 25 June 2015 at 12:06, Robert White > >>> >>> >> > >>> >>> >> wrote: > >>> >>> >>> > >>> >>> >>> Hi Joe, > >>> >>> >>> > >>> >>> >>> Thanks for the reply. > >>> >>> >>> > >>> >>> >>> 2) So maybe I can try to export them? Cos the more thms I get > is > >>> >>> >>> better > >>> >>> >>> for my tests. > >>> >>> >>> but I got more thms when I do this search. Why is that (So far > we > >>> >>> >>> should > >>> >>> >>> have 1214 right? 1214 are those only exported but 1670 are all > of > >>> >>> >>> them (so > >>> >>> >>> far))? > >>> >>> >>> > >>> >>> >>> # List.length (search []) > >>> >>> >>> ;; > >>> >>> >>> val it : int = 1670 > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> On 24 June 2015 at 23:11, Joe Leslie-Hurd > wrote: > >>> >>> >>>> > >>> >>> >>>> Hi Robert, > >>> >>> >>>> > >>> >>> >>>> Welcome back! > >>> >>> >>>> > >>> >>> >>>> 1) There hasn't been much development on OpenTheory in recent > >>> >>> >>>> weeks, > >>> >>> >>>> just some extensions to the natural-divides theory to support > my > >>> >>> >>>> recent blog post on the extended GCD algorithm: > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> > https://gilith.wordpress.com/2015/06/24/natural-number-greatest-common-divisor/ > >>> >>> >>>> > >>> >>> >>>> 2) There is no real reason why those HOL Light theories have > not > >>> >>> >>>> been > >>> >>> >>>> ported to OpenTheory, except that some of them might not be > >>> >>> >>>> needed > >>> >>> >>>> to > >>> >>> >>>> compile a standard theory library (which is a common base of > >>> >>> >>>> theories > >>> >>> >>>> that is expected to be implemented in every theorem prover). > >>> >>> >>>> > >>> >>> >>>> We do not use the database.ml file which lists all the > theorems > >>> >>> >>>> in > >>> >>> >>>> the > >>> >>> >>>> main branch of the HOL Light theorem prover (not the > OpenTheory > >>> >>> >>>> fork). > >>> >>> >>>> But I've just checked in a version of the fork that creates a > >>> >>> >>>> theorem > >>> >>> >>>> database of the standard theory library at the bottom of the > >>> >>> >>>> hol.ml > >>> >>> >>>> file, so after loading with #use "hol.ml";; you can search > the > >>> >>> >>>> database like so: > >>> >>> >>>> > >>> >>> >>>> # search [`MAX (SUC m) (SUC n)`];; > >>> >>> >>>> val it : (string * thm) list = > >>> >>> >>>> [("MAX_SUC", |- !m n. MAX (SUC m) (SUC n) = SUC (MAX m n))] > >>> >>> >>>> > >>> >>> >>>> 3) It looks like you need to extend_the_interpretation before > >>> >>> >>>> loading > >>> >>> >>>> the proofs as described in > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> > >>> >>> >>>> > http://www.gilith.com/pipermail/opentheory-users/2015-June/000515.html > >>> >>> >>>> > >>> >>> >>>> Cheers, > >>> >>> >>>> > >>> >>> >>>> Joe > >>> >>> >>>> > >>> >>> >>>> On Wed, Jun 24, 2015 at 1:31 PM, Robert White > >>> >>> >>>> wrote: > >>> >>> >>>> > Dear Joe and all, > >>> >>> >>>> > > >>> >>> >>>> > I am back to the community! > >>> >>> >>>> > > >>> >>> >>>> > I have the following questions and updates for you: > >>> >>> >>>> > > >>> >>> >>>> > 1) I will be finishing my internship in a few weeks and it > >>> >>> >>>> > would > >>> >>> >>>> > be > >>> >>> >>>> > nice of > >>> >>> >>>> > you if you can give me some description of the most recent > >>> >>> >>>> > updates > >>> >>> >>>> > of > >>> >>> >>>> > OpenTheory. > >>> >>> >>>> > > >>> >>> >>>> > 2) > >>> >>> >>>> > I noticed there is a part not imported to Opentheory (in > >>> >>> >>>> > hol.ml) : > >>> >>> >>>> > > >>> >>> >>>> > (* Not yet ported to OpenTheory > >>> >>> >>>> > loads "calc_int.ml";; (* Calculation with integer-valued > >>> >>> >>>> > reals > >>> >>> >>>> > *) > >>> >>> >>>> > loads "realarith.ml";; (* Universal linear real decision > >>> >>> >>>> > procedure > >>> >>> >>>> > *) > >>> >>> >>>> > loads "real.ml";; (* Derived properties of reals > >>> >>> >>>> > *) > >>> >>> >>>> > loads "calc_rat.ml";; (* Calculation with rational-valued > >>> >>> >>>> > reals > >>> >>> >>>> > *) > >>> >>> >>>> > loads "int.ml";; (* Definition of integers > >>> >>> >>>> > *) > >>> >>> >>>> > loads "iterate.ml";; (* Iterated operations > >>> >>> >>>> > *) > >>> >>> >>>> > loads "cart.ml";; (* Finite Cartesian products > >>> >>> >>>> > *) > >>> >>> >>>> > *) > >>> >>> >>>> > > >>> >>> >>>> > Is there any reason why not? > >>> >>> >>>> > > >>> >>> >>>> > Also, there is a database.ml file. Shall I ignore that in > >>> >>> >>>> > OpenTheory > >>> >>> >>>> > HOL? > >>> >>> >>>> > (since it is not complete anyway) > >>> >>> >>>> > > >>> >>> >>>> > 3) > >>> >>> >>>> > I have problem loading article files: > >>> >>> >>>> > > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/stream.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > >>> >>> >>>> > /home/robert/Project/laholide/opentheory/stream.art > >>> >>> >>>> > at > >>> >>> >>>> > line > >>> >>> >>>> > 1273: defineTypeOp\nstack = [Thm; [\"A\"]; > >>> >>> >>>> > \"Data.Stream.nth\"; > >>> >>> >>>> > \"Data.Stream.fromFunction\"; \"Data.Stream.stream\"; Var; > >>> >>> >>>> > Var; > >>> >>> >>>> > \"Data.Stream.unfold\"; Var; \"Data.Stream.iterate\"; > >>> >>> >>>> > \"Data.Stream.replicate\"]\nunknown type operator > >>> >>> >>>> > \"Data.Stream.stream\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > > "/home/robert/Project/laholide/opentheory/natural-prime.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-prime.art > at > >>> >>> >>>> > line 191: const\nstack = [\"Number.Natural.divides\"; Term; > >>> >>> >>>> > Var; > >>> >>> >>>> > Term; > >>> >>> >>>> > Term; > >>> >>> >>>> > Var; \"Number.Natural.prime\"; Term; Var; [[]; [[Var; > Term]]]; > >>> >>> >>>> > Thm]\nunknown > >>> >>> >>>> > constant \"Number.Natural.divides\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > > >>> >>> >>>> > > "/home/robert/Project/laholide/opentheory/natural-divide.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Sys_error > >>> >>> >>>> > > "/home/robert/Project/laholide/opentheory/natural-divide.art: > >>> >>> >>>> > No > >>> >>> >>>> > such > >>> >>> >>>> > file > >>> >>> >>>> > or directory". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > > >>> >>> >>>> > > "/home/robert/Project/laholide/opentheory/natural-divides.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-divides.art > >>> >>> >>>> > at > >>> >>> >>>> > line 159: defineConst\nstack = [Term; > >>> >>> >>>> > \"Number.Natural.divides\"; > >>> >>> >>>> > Var; > >>> >>> >>>> > Var; > >>> >>> >>>> > []]\nunknown constant \"Number.Natural.divides\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/modular.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > >>> >>> >>>> > /home/robert/Project/laholide/opentheory/modular.art > >>> >>> >>>> > at > >>> >>> >>>> > line > >>> >>> >>>> > 155: const\nstack = [\"Number.Modular.modulus\"; Term; Term; > >>> >>> >>>> > Var; > >>> >>> >>>> > Var; > >>> >>> >>>> > \"Number.Modular.equivalent\"; Term; Var; Term; Var; []; > >>> >>> >>>> > \"HOLLight.modular_to_class\"; > >>> >>> >>>> > \"HOLLight.modular_from_class\"; > >>> >>> >>>> > \"Number.Modular.modular\"; TypeOp; TypeOp; > >>> >>> >>>> > Const]\nunknown > >>> >>> >>>> > constant \"Number.Modular.modulus\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/gfp.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > /home/robert/Project/laholide/opentheory/gfp.art > >>> >>> >>>> > at > >>> >>> >>>> > line > >>> >>> >>>> > 54: > >>> >>> >>>> > const\nstack = [\"Number.GF(p).oddprime\"; Term; Var; > >>> >>> >>>> > []]\nunknown > >>> >>> >>>> > constant > >>> >>> >>>> > \"Number.GF(p).oddprime\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > > >>> >>> >>>> > > "/home/robert/Project/laholide/opentheory/natural-fibonacci.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > >>> >>> >>>> > > /home/robert/Project/laholide/opentheory/natural-fibonacci.art > >>> >>> >>>> > at line 1933: defineConstList\nstack = [Thm; > >>> >>> >>>> > [[\"Number.Natural.Fibonacci.zeckendorf\"; Var]]; Var; []; > >>> >>> >>>> > Thm]\nunknown > >>> >>> >>>> > constant \"Number.Natural.Fibonacci.zeckendorf\"". > >>> >>> >>>> > # let p = load_proofs > >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/word.art";; > >>> >>> >>>> > Exception: > >>> >>> >>>> > Failure > >>> >>> >>>> > "in article > /home/robert/Project/laholide/opentheory/word.art > >>> >>> >>>> > at > >>> >>> >>>> > line > >>> >>> >>>> > 130: > >>> >>> >>>> > const\nstack = [\"Data.Word.width\"; Term; > >>> >>> >>>> > \"Data.Word.modulus\"; > >>> >>> >>>> > Thm; > >>> >>> >>>> > Thm]\nunknown constant \"Data.Word.width\"". > >>> >>> >>>> > # > >>> >>> >>>> > > >>> >>> >>>> > Could you please help on that? It seems I can't even play > with > >>> >>> >>>> > the > >>> >>> >>>> > other > >>> >>> >>>> > article files I used to be able to load either :( > >>> >>> >>>> > > >>> >>> >>>> > Thanks very much! > >>> >>> >>>> > > >>> >>> >>>> > -- > >>> >>> >>>> > > >>> >>> >>>> > Regards, > >>> >>> >>>> > Robert White (Shuai Wang) > >>> >>> >>>> > INRIA Deducteam > >>> >>> >>>> > [Moving to ILLC of UvA from this Sep to continue my > masters. ] > >>> >>> >>>> > [New email address will be shuai.wang at student.uva.nl] > >>> >>> >>>> > > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> > >>> >>> >>> -- > >>> >>> >>> > >>> >>> >>> Regards, > >>> >>> >>> Robert White (Shuai Wang) > >>> >>> >>> INRIA Deducteam > >>> >>> >>> [Moving to ILLC of UvA from this Sep to continue my masters. ] > >>> >>> >>> [New email address will be shuai.wang at student.uva.nl] > >>> >>> >>> > >>> >>> >> > >>> >>> >> > >>> >>> >> > >>> >>> >> -- > >>> >>> >> > >>> >>> >> Regards, > >>> >>> >> Robert White (Shuai Wang) > >>> >>> >> INRIA Deducteam > >>> >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] > >>> >>> >> [New email address will be shuai.wang at student.uva.nl] > >>> >>> >> > >>> >>> > > >>> >>> > > >>> >>> > > >>> >>> > -- > >>> >>> > > >>> >>> > Regards, > >>> >>> > Robert White (Shuai Wang) > >>> >>> > INRIA Deducteam > >>> >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] > >>> >>> > [New email address will be shuai.wang at student.uva.nl] > >>> >>> > > >>> >> > >>> >> > >>> >> > >>> >> > >>> >> -- > >>> >> > >>> >> Regards, > >>> >> Robert White (Shuai Wang) > >>> >> INRIA Deducteam > >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] > >>> >> [New email address will be shuai.wang at student.uva.nl] > >>> >> > >>> > > >>> > > >>> > > >>> > -- > >>> > > >>> > Regards, > >>> > Robert White (Shuai Wang) > >>> > INRIA Deducteam > >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] > >>> > [New email address will be shuai.wang at student.uva.nl] > >>> > > >> > >> > >> > >> > >> -- > >> > >> Regards, > >> Robert White (Shuai Wang) > >> INRIA Deducteam > >> [Moving to ILLC of UvA from this Sep to continue my masters. ] > >> [New email address will be shuai.wang at student.uva.nl] > >> > > > > > > > > -- > > > > Regards, > > Robert White (Shuai Wang) > > INRIA Deducteam > > [Moving to ILLC of UvA from this Sep to continue my masters. ] > > [New email address will be shuai.wang at student.uva.nl] > > > -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.robert.wangshuai at gmail.com Thu Jul 2 16:39:09 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Thu, 2 Jul 2015 18:39:09 +0200 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: Oh no. So does that mean the import function would have to be updated then. On Jul 2, 2015 5:58 PM, "Joe Leslie-Hurd" wrote: > Hi Michael, > > I think your statement is correct, because both HOL Light and HOL4 use > predicates rather than an explicit set type, so if OpenTheory also > used predicates it would simplify translation between these two > environments. And indeed, it complicates export if an explicit set > type has to be reconstructed from predicates. > > However, one design principle of OpenTheory is that whenever there is > a trade-off between simplifying import or export then it's better to > simplify importing, and in this case it's easy to drop the explicit > set type in favour of predicates during import. > > And there are other environments that do implement explicit set types, > such as Haskell. When exporting theories as Haskell packages I want to > export explicit sets as Haskell sets, which would be difficult if > OpenTheory used predicates. > > Cheers, > > Joe > > On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish > wrote: > > > >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: > > > >> However, I can answer your question right now. I do want the > >> OpenTheory fork of HOL Light to be as close as possible to the main > >> trunk of HOL Light, but there are certain changes that are required to > >> export a standard theory library (which is the primary purpose of this > >> fork). For example, introducing an explicit set type (A set) rather > >> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 > >> = 0) are necessary to ensure the standard theory library can be used > >> in as many environments as possible. > > > > Is it not now our experience that providing an explicit set type > actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? > > > > Michael > > > > ________________________________ > > > > The information in this e-mail may be confidential and subject to legal > professional privilege and/or copyright. National ICT Australia Limited > accepts no liability for any damage caused by this email or its attachments. > > > > _______________________________________________ > > 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 Jul 2 20:29:07 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 2 Jul 2015 13:29:07 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: Hi Robert, That depends - into which system are you planning on importing OpenTheory theories? Cheers, Joe On Thu, Jul 2, 2015 at 9:39 AM, Robert White wrote: > Oh no. So does that mean the import function would have to be updated then. > > On Jul 2, 2015 5:58 PM, "Joe Leslie-Hurd" wrote: >> >> Hi Michael, >> >> I think your statement is correct, because both HOL Light and HOL4 use >> predicates rather than an explicit set type, so if OpenTheory also >> used predicates it would simplify translation between these two >> environments. And indeed, it complicates export if an explicit set >> type has to be reconstructed from predicates. >> >> However, one design principle of OpenTheory is that whenever there is >> a trade-off between simplifying import or export then it's better to >> simplify importing, and in this case it's easy to drop the explicit >> set type in favour of predicates during import. >> >> And there are other environments that do implement explicit set types, >> such as Haskell. When exporting theories as Haskell packages I want to >> export explicit sets as Haskell sets, which would be difficult if >> OpenTheory used predicates. >> >> Cheers, >> >> Joe >> >> On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish >> wrote: >> > >> >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: >> > >> >> However, I can answer your question right now. I do want the >> >> OpenTheory fork of HOL Light to be as close as possible to the main >> >> trunk of HOL Light, but there are certain changes that are required to >> >> export a standard theory library (which is the primary purpose of this >> >> fork). For example, introducing an explicit set type (A set) rather >> >> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 >> >> = 0) are necessary to ensure the standard theory library can be used >> >> in as many environments as possible. >> > >> > Is it not now our experience that providing an explicit set type >> > actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? >> > >> > Michael >> > >> > ________________________________ >> > >> > The information in this e-mail may be confidential and subject to legal >> > professional privilege and/or copyright. National ICT Australia Limited >> > accepts no liability for any damage caused by this email or its attachments. >> > >> > _______________________________________________ >> > opentheory-users mailing list >> > opentheory-users at gilith.com >> > http://www.gilith.com/mailman/listinfo/opentheory-users From ai.robert.wangshuai at gmail.com Thu Jul 2 20:50:45 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Thu, 2 Jul 2015 22:50:45 +0200 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: The HOL light fork and Holide? Or maybe I dont need to worry about it as long as you don't change the article files? On Jul 2, 2015 10:29 PM, "Joe Leslie-Hurd" wrote: > Hi Robert, > > That depends - into which system are you planning on importing > OpenTheory theories? > > Cheers, > > Joe > > On Thu, Jul 2, 2015 at 9:39 AM, Robert White > wrote: > > Oh no. So does that mean the import function would have to be updated > then. > > > > On Jul 2, 2015 5:58 PM, "Joe Leslie-Hurd" wrote: > >> > >> Hi Michael, > >> > >> I think your statement is correct, because both HOL Light and HOL4 use > >> predicates rather than an explicit set type, so if OpenTheory also > >> used predicates it would simplify translation between these two > >> environments. And indeed, it complicates export if an explicit set > >> type has to be reconstructed from predicates. > >> > >> However, one design principle of OpenTheory is that whenever there is > >> a trade-off between simplifying import or export then it's better to > >> simplify importing, and in this case it's easy to drop the explicit > >> set type in favour of predicates during import. > >> > >> And there are other environments that do implement explicit set types, > >> such as Haskell. When exporting theories as Haskell packages I want to > >> export explicit sets as Haskell sets, which would be difficult if > >> OpenTheory used predicates. > >> > >> Cheers, > >> > >> Joe > >> > >> On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish > >> wrote: > >> > > >> >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: > >> > > >> >> However, I can answer your question right now. I do want the > >> >> OpenTheory fork of HOL Light to be as close as possible to the main > >> >> trunk of HOL Light, but there are certain changes that are required > to > >> >> export a standard theory library (which is the primary purpose of > this > >> >> fork). For example, introducing an explicit set type (A set) rather > >> >> than the predicate (A -> bool) and removing default cases (e.g., PRE > 0 > >> >> = 0) are necessary to ensure the standard theory library can be used > >> >> in as many environments as possible. > >> > > >> > Is it not now our experience that providing an explicit set type > >> > actually makes it *harder* to use OpenTheory in both HOL4 and HOL > Light? > >> > > >> > Michael > >> > > >> > ________________________________ > >> > > >> > The information in this e-mail may be confidential and subject to > legal > >> > professional privilege and/or copyright. National ICT Australia > Limited > >> > accepts no liability for any damage caused by this email or its > attachments. > >> > > >> > _______________________________________________ > >> > 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 Jul 2 20:53:31 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 2 Jul 2015 13:53:31 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: Hi Robert, I'm afraid I may have been confusing. The OpenTheory standard library has always had an explicit set type, and will continue to do so (knowing what I know now, anyway). So you shouldn't need to change anything. Cheers, Joe On Thu, Jul 2, 2015 at 1:50 PM, Robert White wrote: > The HOL light fork and Holide? Or maybe I dont need to worry about it as > long as you don't change the article files? > > On Jul 2, 2015 10:29 PM, "Joe Leslie-Hurd" wrote: >> >> Hi Robert, >> >> That depends - into which system are you planning on importing >> OpenTheory theories? >> >> Cheers, >> >> Joe >> >> On Thu, Jul 2, 2015 at 9:39 AM, Robert White >> wrote: >> > Oh no. So does that mean the import function would have to be updated >> > then. >> > >> > On Jul 2, 2015 5:58 PM, "Joe Leslie-Hurd" wrote: >> >> >> >> Hi Michael, >> >> >> >> I think your statement is correct, because both HOL Light and HOL4 use >> >> predicates rather than an explicit set type, so if OpenTheory also >> >> used predicates it would simplify translation between these two >> >> environments. And indeed, it complicates export if an explicit set >> >> type has to be reconstructed from predicates. >> >> >> >> However, one design principle of OpenTheory is that whenever there is >> >> a trade-off between simplifying import or export then it's better to >> >> simplify importing, and in this case it's easy to drop the explicit >> >> set type in favour of predicates during import. >> >> >> >> And there are other environments that do implement explicit set types, >> >> such as Haskell. When exporting theories as Haskell packages I want to >> >> export explicit sets as Haskell sets, which would be difficult if >> >> OpenTheory used predicates. >> >> >> >> Cheers, >> >> >> >> Joe >> >> >> >> On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish >> >> wrote: >> >> > >> >> >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: >> >> > >> >> >> However, I can answer your question right now. I do want the >> >> >> OpenTheory fork of HOL Light to be as close as possible to the main >> >> >> trunk of HOL Light, but there are certain changes that are required >> >> >> to >> >> >> export a standard theory library (which is the primary purpose of >> >> >> this >> >> >> fork). For example, introducing an explicit set type (A set) rather >> >> >> than the predicate (A -> bool) and removing default cases (e.g., PRE >> >> >> 0 >> >> >> = 0) are necessary to ensure the standard theory library can be used >> >> >> in as many environments as possible. >> >> > >> >> > Is it not now our experience that providing an explicit set type >> >> > actually makes it *harder* to use OpenTheory in both HOL4 and HOL >> >> > Light? >> >> > >> >> > Michael >> >> > >> >> > ________________________________ >> >> > >> >> > The information in this e-mail may be confidential and subject to >> >> > legal >> >> > professional privilege and/or copyright. National ICT Australia >> >> > Limited >> >> > accepts no liability for any damage caused by this email or its >> >> > attachments. >> >> > >> >> > _______________________________________________ >> >> > opentheory-users mailing list >> >> > opentheory-users at gilith.com >> >> > http://www.gilith.com/mailman/listinfo/opentheory-users From ai.robert.wangshuai at gmail.com Thu Jul 2 22:01:44 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Fri, 3 Jul 2015 00:01:44 +0200 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: Sorry I don't know enough about that. I am just a master student. Anyway, good to hear that. Looking forward to the updates. On Jul 2, 2015 10:53 PM, "Joe Leslie-Hurd" wrote: > Hi Robert, > > I'm afraid I may have been confusing. The OpenTheory standard library > has always had an explicit set type, and will continue to do so > (knowing what I know now, anyway). So you shouldn't need to change > anything. > > Cheers, > > Joe > > On Thu, Jul 2, 2015 at 1:50 PM, Robert White > wrote: > > The HOL light fork and Holide? Or maybe I dont need to worry about it as > > long as you don't change the article files? > > > > On Jul 2, 2015 10:29 PM, "Joe Leslie-Hurd" wrote: > >> > >> Hi Robert, > >> > >> That depends - into which system are you planning on importing > >> OpenTheory theories? > >> > >> Cheers, > >> > >> Joe > >> > >> On Thu, Jul 2, 2015 at 9:39 AM, Robert White > >> wrote: > >> > Oh no. So does that mean the import function would have to be updated > >> > then. > >> > > >> > On Jul 2, 2015 5:58 PM, "Joe Leslie-Hurd" wrote: > >> >> > >> >> Hi Michael, > >> >> > >> >> I think your statement is correct, because both HOL Light and HOL4 > use > >> >> predicates rather than an explicit set type, so if OpenTheory also > >> >> used predicates it would simplify translation between these two > >> >> environments. And indeed, it complicates export if an explicit set > >> >> type has to be reconstructed from predicates. > >> >> > >> >> However, one design principle of OpenTheory is that whenever there is > >> >> a trade-off between simplifying import or export then it's better to > >> >> simplify importing, and in this case it's easy to drop the explicit > >> >> set type in favour of predicates during import. > >> >> > >> >> And there are other environments that do implement explicit set > types, > >> >> such as Haskell. When exporting theories as Haskell packages I want > to > >> >> export explicit sets as Haskell sets, which would be difficult if > >> >> OpenTheory used predicates. > >> >> > >> >> Cheers, > >> >> > >> >> Joe > >> >> > >> >> On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish > >> >> wrote: > >> >> > > >> >> >> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: > >> >> > > >> >> >> However, I can answer your question right now. I do want the > >> >> >> OpenTheory fork of HOL Light to be as close as possible to the > main > >> >> >> trunk of HOL Light, but there are certain changes that are > required > >> >> >> to > >> >> >> export a standard theory library (which is the primary purpose of > >> >> >> this > >> >> >> fork). For example, introducing an explicit set type (A set) > rather > >> >> >> than the predicate (A -> bool) and removing default cases (e.g., > PRE > >> >> >> 0 > >> >> >> = 0) are necessary to ensure the standard theory library can be > used > >> >> >> in as many environments as possible. > >> >> > > >> >> > Is it not now our experience that providing an explicit set type > >> >> > actually makes it *harder* to use OpenTheory in both HOL4 and HOL > >> >> > Light? > >> >> > > >> >> > Michael > >> >> > > >> >> > ________________________________ > >> >> > > >> >> > The information in this e-mail may be confidential and subject to > >> >> > legal > >> >> > professional privilege and/or copyright. National ICT Australia > >> >> > Limited > >> >> > accepts no liability for any damage caused by this email or its > >> >> > attachments. > >> >> > > >> >> > _______________________________________________ > >> >> > 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 ai.robert.wangshuai at gmail.com Sun Jul 5 15:51:41 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Sun, 5 Jul 2015 17:51:41 +0200 Subject: [opentheory-users] Question about Lazy-list In-Reply-To: References: Message-ID: Dear Ramana (and Joe as cc-ed), We found the error and I have manged to update Holide2 and it turned out that there was an unbounded type variable somewhere in the proof (not from the conclusion, but from something like EQ_MP). Now that this is manged by the new version of Holide, all the existing packages are verified by Holide2+Dedukti. Yappy! Regards, Robert On 9 June 2015 at 15:23, Robert White wrote: > Dear Joe and Ramana, > > It looks like we have a small problem on our side (very hard to notice). > Both versions of Holide failed. We are trying to fix this bug. Will let you > know how it goes. > Thanks > Regards, > Robert > > On 8 June 2015 at 18:17, Joe Leslie-Hurd wrote: > >> It is possibly helpful to note that every prefix of a valid article is >> a valid article (as long as you break at a newline), so if you need a >> smaller testcase you could delete everything after some newline in >> llist.art. >> >> Cheers, >> >> Joe >> >> On Mon, Jun 8, 2015 at 9:13 AM, Robert White >> wrote: >> > Thanks for the link. >> > >> >> If the article is accepted by the opentheory tool but not by Dedukti, >> >> perhaps there is a problem in Holide or in the Dedukti checker? >> > >> > I have also been diving into it on my side to see where the problem >> could >> > be. >> > >> > Thanks for your advice. I will try that. >> > >> > Regards, >> > Robert >> > >> > On 8 June 2015 at 17:58, Ramana Kumar wrote: >> >> >> >> Hi Robert, >> >> >> >> The article was generated following the instructions at >> >> http://www.gilith.com/research/opentheory/faq.html#export-from-hol4 >> applied >> >> to llistScript.sml. >> >> >> >> If the article is accepted by the opentheory tool but not by Dedukti, >> >> perhaps there is a problem in Holide or in the Dedukti checker? >> >> >> >> For debugging maybe you could try exporting only a part of >> llistScript.sml >> >> (by deleting the rest). Or even translating only a small part of the >> >> generated llist.art to Dedukti. >> >> >> >> Cheers, >> >> Ramana >> >> >> >> On 8 June 2015 at 16:45, Robert White >> >> wrote: >> >>> >> >>> Dear Ramana, >> >>> >> >>> I am not sure how to deal with it. Do you have any advice please. I am >> >>> not familiar with generating / extracting *.art files. Neither >> debugging >> >>> though a .art file. >> >>> >> >>> Thanks >> >>> >> >>> On 8 June 2015 at 17:36, Ramana Kumar wrote: >> >>>> >> >>>> The lazy-list package is based on a HOL4 theory of lazy lists, which >> can >> >>>> be found here: >> >>>> https://github.com/HOL-Theorem-Prover/HOL/tree/master/src/llist. >> >>>> >> >>>> On 8 June 2015 at 16:33, Robert White > > >> >>>> wrote: >> >>>>> >> >>>>> Thanks Joe, >> >>>>> >> >>>>> I will wait for further updates then. >> >>>>> >> >>>>> Regards, >> >>>>> Robert >> >>>>> >> >>>>> On 8 June 2015 at 17:31, Joe Leslie-Hurd wrote: >> >>>>>> >> >>>>>> Hi Robert, >> >>>>>> >> >>>>>> In terms of the OpenTheory package, you are correct that lazy-list >> is >> >>>>>> monolithic: >> >>>>>> >> >>>>>> $ opentheory info --theory-source lazy-list >> >>>>>> main { >> >>>>>> article: "llist.art" >> >>>>>> } >> >>>>>> >> >>>>>> However, Ramana may be able to dig up source files for the article >> >>>>>> that could be restructured into subpackages. >> >>>>>> >> >>>>>> Cheers, >> >>>>>> >> >>>>>> Joe >> >>>>>> >> >>>>>> On Mon, Jun 8, 2015 at 2:44 AM, Robert White >> >>>>>> wrote: >> >>>>>> > Dear Joe and Ramana, >> >>>>>> > >> >>>>>> > I used the new Holide and dedukti for proof checking of the whole >> >>>>>> > Opentheory >> >>>>>> > repos. There is one good news and one bad news. >> >>>>>> > >> >>>>>> > The good news is: >> >>>>>> > >> >>>>>> > I have checked through the whole library of the rest apart from >> >>>>>> > lazy-list >> >>>>>> > without problems. They all passed the checking. >> >>>>>> > >> >>>>>> > The bad news is: >> >>>>>> > >> >>>>>> > lazy-list didn't pass the check. >> >>>>>> > >> >>>>>> > --------this is the error line by Dedukti >> >>>>>> > -------------------------------- >> >>>>>> > Processing file 'dedukti/lazy-list.dk'... >> >>>>>> > ERROR line:106697 column:149 Cannot find symbol 'lazy_2Dlist.A'. >> >>>>>> > >> >>>>>> > I searched online and found there isn't sub-packages for me to >> check >> >>>>>> > individually. I wonder if this one is just as a big whole file or >> >>>>>> > maybe I >> >>>>>> > can somehow unpack it to different files and check through each >> >>>>>> > individually. >> >>>>>> > >> >>>>>> > Thanks! >> >>>>>> > -- >> >>>>>> > >> >>>>>> > Regards, >> >>>>>> > Robert White (Shuai Wang) >> >>>>>> > INRIA Deducteam >> >>>>>> > [Moving to ILLC of UvA from this Sep. ] >> >>>>>> > [New email address will be shuai.wang at student.uva.nl] >> >>>>>> > >> >>>>> >> >>>>> >> >>>>> >> >>>>> >> >>>>> -- >> >>>>> >> >>>>> Regards, >> >>>>> Robert White (Shuai Wang) >> >>>>> INRIA Deducteam >> >>>>> [Moving to ILLC of UvA from this Sep. ] >> >>>>> [New email address will be shuai.wang at student.uva.nl] >> >>>>> >> >>>> >> >>> >> >>> >> >>> >> >>> -- >> >>> >> >>> Regards, >> >>> Robert White (Shuai Wang) >> >>> INRIA Deducteam >> >>> [Moving to ILLC of UvA from this Sep. ] >> >>> [New email address will be shuai.wang at student.uva.nl] >> >>> >> >>> >> >>> _______________________________________________ >> >>> opentheory-users mailing list >> >>> opentheory-users at gilith.com >> >>> http://www.gilith.com/mailman/listinfo/opentheory-users >> >>> >> >> >> > >> > >> > >> > -- >> > >> > Regards, >> > Robert White (Shuai Wang) >> > INRIA Deducteam >> > [Moving to ILLC of UvA from this Sep. ] >> > [New email address will be shuai.wang at student.uva.nl] >> > >> > >> > _______________________________________________ >> > 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 >> > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > > -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Mon Jul 6 10:54:44 2015 From: ramana at member.fsf.org (Ramana Kumar) Date: Mon, 6 Jul 2015 11:54:44 +0100 Subject: [opentheory-users] importer for Isabelle In-Reply-To: References: Message-ID: Yes, if it works (or is close to working) I would like to get it incorporated into the Isabelle codebase. I'm not yet sure how to contribute things to Isabelle, but I imagine I'll find out within the next few months. On 23 May 2015 at 15:52, Brian Huffman wrote: > I've hardly looked at it since I wrote it. It was never incorporated > into the Isabelle codebase. I suppose it would probably work with the > latest Isabelle, because it uses only the low-level proof kernel api, > which doesn't change much any more. > > I'll have to look around to see where I have a copy of the source > code; that was a couple of computers ago. Did you want to try to do > something with it? > > - Brian > > > On Sat, May 23, 2015 at 5:13 AM, Ramana Kumar > wrote: > > Hi Brian, > > > > What's the status of your OpenTheory importer? Does it work with the > > latest Isabelle? Was it incorporated into the main code base? > > > > Cheers, > > Ramana > > > > On 15 April 2011 at 17:34, Brian Huffman wrote: > >> On Thu, Apr 14, 2011 at 7:03 PM, Joe Hurd wrote: > >>> Hi Brian, > >>> > >>> That is really great work! Am I right in thinking you can import the > >>> parser-1.5 article binding all the input symbols and axioms to > >>> existing ones in Isabelle? I would have guessed that Isabelle type > >>> classes would have managed to get in the way at some point, but > >>> perhaps this would only be for converting Isabelle proofs to > >>> OpenTheory format? > >> > >> Yes, each of the input constants of the article is mapped to a > >> pre-existing Isabelle constant. Some of these existing Isabelle > >> constants happen to be overloaded, but that doesn't cause any > >> problems. This mapping of constant names does not even need to be > >> one-to-one; for example, I imagine that "Number.Natural.+" and > >> "Number.Integer.+" would map to the same overloaded "plus" constant in > >> Isabelle. > >> > >> Of course, exporting proofs from Isabelle is a completely different > story. > >> > >>> You mentioned that you prove a lot of theorems that the OpenTheory > >>> article relies on, but it seems you could reduce this by processing a > >>> set of OpenTheory packages that don't make any definitions. When I was > >>> designing the standard theory library I tried to isolate packages that > >>> made definitions and have them export just a minimal theorem interface > >>> - most of the theorems are proved in packages that make no definitions > >>> and so can be safely run to populate the [opentheory] set of theorems. > >> > >> Your idea of keeping definitions in separate, minimal modules is a > >> good design. I'm sure I could have greatly reduced the number of > >> [opentheory] lemmas that I needed by finding the right additional > >> article files to import; I was just too lazy to figure out how the > >> packages were organized. > >> > >>>> The importer should also extend these tables whenever it defines a new > >>>> constant or type, but I haven't implemented this yet. Another nice > >>>> feature would be a way for users to influence how the importer chooses > >>>> names for newly-defined constants and types. Right now it takes the > >>>> names directly from the strings in the article file, which isn't so > >>>> nice for names like "HOLLight._dest_rec" (Isabelle's parser can't > >>>> handle names that start with underscores). > >>> > >>> You should find that constants and type operators with names like this > >>> are never exported from a theory (i.e., never appear in exported > >>> theorems), so it's perfectly safe to normalize their names to > >>> something more acceptable to Isabelle. They are `local definitions' > >>> that are used only in proofs. > >> > >> Actually, it seems like it would be safe to rename *any* constant > >> (whether exported or not) to any name that I want in Isabelle, as long > >> as the importer keeps track of the name mapping so that later imports > >> can use the same names. > >> > >> I suppose I should write an "import_name" function that converts from > >> OpenTheory names to Isabelle-friendly ones. It would be nice to > >> parameterize this by a list of user-specified exceptions to the > >> mapping, so you could say something like, "import this article, but > >> when you define constant 'foo', call it 'bar' instead." > >> > >>>> Once I clean up the code, I'm not sure what I should do with it... I > >>>> suppose I could add it to the Isabelle repo, but I'm not sure if I > >>>> want to advertise to Munich crowd that I've been doing all this work > >>>> that is unrelated to finishing my thesis :) > >>> > >>> I would very much like to see it live on in some fashion - my hope is > >>> that more and more theories will be converted to OpenTheory packages, > >>> and your code could be used to import them into Isabelle in a > >>> principled way. > >> > >> I suppose I'll add it to the Isabelle distribution at some point, > >> maybe after I finish writing my thesis. In the meantime, I guess I can > >> post the code to the list, so it will be archived and people can try > >> it out. > >> > >> - Brian > >> > >> _______________________________________________ > >> opentheory-users mailing list > >> opentheory-users at gilith.com > >> http://www.gilith.com/mailman/listinfo/opentheory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Michael.Norrish at nicta.com.au Tue Jul 7 05:51:43 2015 From: Michael.Norrish at nicta.com.au (Michael Norrish) Date: Tue, 7 Jul 2015 05:51:43 +0000 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> Message-ID: <773696E1-502A-4D08-87C2-2D4F1C5B498B@nicta.com.au> That?s a nice explanation; thanks. So here?s the next question: how should we best establish a name space for inter-operation between HOL Light and HOL4 that doesn?t use the OpenTheory library, and prefers instead to use sets as predicates? Such a namespace would still have to figure out what to do with numerals, but hey. Michael > On 3 Jul 2015, at 01:58, Joe Leslie-Hurd wrote: > > Hi Michael, > > I think your statement is correct, because both HOL Light and HOL4 use > predicates rather than an explicit set type, so if OpenTheory also > used predicates it would simplify translation between these two > environments. And indeed, it complicates export if an explicit set > type has to be reconstructed from predicates. > > However, one design principle of OpenTheory is that whenever there is > a trade-off between simplifying import or export then it's better to > simplify importing, and in this case it's easy to drop the explicit > set type in favour of predicates during import. > > And there are other environments that do implement explicit set types, > such as Haskell. When exporting theories as Haskell packages I want to > export explicit sets as Haskell sets, which would be difficult if > OpenTheory used predicates. > > Cheers, > > Joe > > On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish > wrote: >> >>> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: >> >>> However, I can answer your question right now. I do want the >>> OpenTheory fork of HOL Light to be as close as possible to the main >>> trunk of HOL Light, but there are certain changes that are required to >>> export a standard theory library (which is the primary purpose of this >>> fork). For example, introducing an explicit set type (A set) rather >>> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 >>> = 0) are necessary to ensure the standard theory library can be used >>> in as many environments as possible. >> >> Is it not now our experience that providing an explicit set type actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? >> >> Michael >> >> ________________________________ >> >> The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. >> >> _______________________________________________ >> 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 Wed Jul 8 15:17:24 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 8 Jul 2015 08:17:24 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: References: Message-ID: Hi Robert, I have now completed the merge of the OpenTheory fork of HOL Light with the trunk, and the standard theory library now contains 1231 theorems (up from 1214). You can get the latest version of the OpenTheory fork of HOL Light simply by executing a git pull, and you can install the latest version (base-1.200) of the standard theory library using opentheory update opentheory upgrade Cheers, Joe On Wed, Jul 1, 2015 at 3:09 PM, Robert White wrote: > Okay then. Looks like I have to use the old data for testing then. > Please let me know when it's updated :) > > Thanks a lot > Robert > > On 1 July 2015 at 22:57, Joe Leslie-Hurd wrote: >> >> Hi Robert, >> >> Sorry, I haven't been able to do the merge yet (it's a bit fiddly, so >> it requires an uninterrupted block of time which is a scarce resource >> for me right now). >> >> However, I can answer your question right now. I do want the >> OpenTheory fork of HOL Light to be as close as possible to the main >> trunk of HOL Light, but there are certain changes that are required to >> export a standard theory library (which is the primary purpose of this >> fork). For example, introducing an explicit set type (A set) rather >> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 >> = 0) are necessary to ensure the standard theory library can be used >> in as many environments as possible. >> >> Cheers, >> >> Joe >> >> >> >> On Wed, Jul 1, 2015 at 1:30 PM, Robert White >> wrote: >> > Dear Joe, >> > >> > Is there any updates on this? >> > >> > Regards, >> > Robert >> > >> > On 29 June 2015 at 21:04, Robert White >> > wrote: >> >> >> >> Dear Joe, >> >> >> >> Thanks for the reply. I am looking forward to the updates! >> >> >> >> Here are things I found which might be useful for you: >> >> >> >> 1) >> >> Looks like there is something wrong going on there in sum.ml: >> >> Exception: Failure "REFL_TAC". >> >> Error in included file ----/hol_light/opentheory/stdlib/sum.ml >> >> >> >> 2) There is no CASES_TAC in the most up-to-date version of HOL Light. >> >> >> >> Questions: >> >> 1) Why do you want things to be different? >> >> >> >> Cheers >> >> Robert >> >> >> >> >> >> >> >> >> >> On 29 June 2015 at 20:30, Joe Leslie-Hurd wrote: >> >>> >> >>> Hi Robert, >> >>> >> >>> In general there are quite a few differences in definitions and >> >>> theorems between the OpenTheory fork of HOL Light and the trunk, and >> >>> some of that is here to stay (e.g., the explicit type of sets in the >> >>> OpenTheory fork). >> >>> >> >>> That said, it's past time to do a merge with the HOL Light trunk and >> >>> create a new version of the standard theory library: I will work on >> >>> this. >> >>> >> >>> Cheers, >> >>> >> >>> Joe >> >>> >> >>> >> >>> On Mon, Jun 29, 2015 at 10:43 AM, Robert White >> >>> wrote: >> >>> > Dear Joe, >> >>> > >> >>> > I tried to update the arith.ml file. It seems more complicated than >> >>> > I >> >>> > expected. >> >>> > For example, we have LE_ZERO but the new version deleted it. >> >>> > >> >>> > So shall I continue or maybe you have better advice? >> >>> > Regards, >> >>> > Robert >> >>> > >> >>> > On 29 June 2015 at 19:16, Robert White >> >>> > >> >>> > wrote: >> >>> >> >> >>> >> Dear Joe, >> >>> >> I think HOL Light is more updated. We maybe need to export some >> >>> >> files >> >>> >> again. >> >>> >> For example. the arith.ml >> >>> >> The first missing thm is ADD_SUBR, while in the up-to-date HOL >> >>> >> Light >> >>> >> they >> >>> >> have ADD_SUBR defined but not in OpenTheory HOL. >> >>> >> So I have the feeling that we need to generate the base.art again I >> >>> >> think? >> >>> >> >> >>> >> Regards, >> >>> >> Robert >> >>> >> >> >>> >> >> >>> >> On 26 June 2015 at 06:44, Joe Leslie-Hurd wrote: >> >>> >>> >> >>> >>> Hi Robert, >> >>> >>> >> >>> >>> This is a mystery to me: perhaps there are many theorems deleted >> >>> >>> in >> >>> >>> the OpenTheory fork of HOL Light compared to the standard >> >>> >>> distribution >> >>> >>> (which is what the database.ml file records)? >> >>> >>> >> >>> >>> Cheers, >> >>> >>> >> >>> >>> Joe >> >>> >>> >> >>> >>> >> >>> >>> On Thu, Jun 25, 2015 at 3:26 AM, Robert White >> >>> >>> wrote: >> >>> >>> > Hi again. >> >>> >>> > >> >>> >>> > There are over 2200 thms in the hol database.ml but there are >> >>> >>> > "to >> >>> >>> > the >> >>> >>> > most"[1] 1885 thms. So where are the rest? >> >>> >>> > >> >>> >>> > [1]I tried to load the files commented out in hol.ml. >> >>> >>> > >> >>> >>> > >> >>> >>> > On 25 June 2015 at 12:16, Robert White >> >>> >>> > >> >>> >>> > wrote: >> >>> >>> >> >> >>> >>> >> Hi Joe, >> >>> >>> >> >> >>> >>> >> So I tested the HOL "theorems" also, Here are the results: >> >>> >>> >> # List.length(!theorems);; >> >>> >>> >> val it : int = 1670 >> >>> >>> >> >> >>> >>> >> So that means there are 1670 - 1214 = 456 theorems not exported >> >>> >>> >> to >> >>> >>> >> Opentheory? >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> On 25 June 2015 at 12:06, Robert White >> >>> >>> >> >> >>> >>> >> wrote: >> >>> >>> >>> >> >>> >>> >>> Hi Joe, >> >>> >>> >>> >> >>> >>> >>> Thanks for the reply. >> >>> >>> >>> >> >>> >>> >>> 2) So maybe I can try to export them? Cos the more thms I get >> >>> >>> >>> is >> >>> >>> >>> better >> >>> >>> >>> for my tests. >> >>> >>> >>> but I got more thms when I do this search. Why is that (So far >> >>> >>> >>> we >> >>> >>> >>> should >> >>> >>> >>> have 1214 right? 1214 are those only exported but 1670 are all >> >>> >>> >>> of >> >>> >>> >>> them (so >> >>> >>> >>> far))? >> >>> >>> >>> >> >>> >>> >>> # List.length (search []) >> >>> >>> >>> ;; >> >>> >>> >>> val it : int = 1670 >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> On 24 June 2015 at 23:11, Joe Leslie-Hurd >> >>> >>> >>> wrote: >> >>> >>> >>>> >> >>> >>> >>>> Hi Robert, >> >>> >>> >>>> >> >>> >>> >>>> Welcome back! >> >>> >>> >>>> >> >>> >>> >>>> 1) There hasn't been much development on OpenTheory in recent >> >>> >>> >>>> weeks, >> >>> >>> >>>> just some extensions to the natural-divides theory to support >> >>> >>> >>>> my >> >>> >>> >>>> recent blog post on the extended GCD algorithm: >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> https://gilith.wordpress.com/2015/06/24/natural-number-greatest-common-divisor/ >> >>> >>> >>>> >> >>> >>> >>>> 2) There is no real reason why those HOL Light theories have >> >>> >>> >>>> not >> >>> >>> >>>> been >> >>> >>> >>>> ported to OpenTheory, except that some of them might not be >> >>> >>> >>>> needed >> >>> >>> >>>> to >> >>> >>> >>>> compile a standard theory library (which is a common base of >> >>> >>> >>>> theories >> >>> >>> >>>> that is expected to be implemented in every theorem prover). >> >>> >>> >>>> >> >>> >>> >>>> We do not use the database.ml file which lists all the >> >>> >>> >>>> theorems >> >>> >>> >>>> in >> >>> >>> >>>> the >> >>> >>> >>>> main branch of the HOL Light theorem prover (not the >> >>> >>> >>>> OpenTheory >> >>> >>> >>>> fork). >> >>> >>> >>>> But I've just checked in a version of the fork that creates a >> >>> >>> >>>> theorem >> >>> >>> >>>> database of the standard theory library at the bottom of the >> >>> >>> >>>> hol.ml >> >>> >>> >>>> file, so after loading with #use "hol.ml";; you can search >> >>> >>> >>>> the >> >>> >>> >>>> database like so: >> >>> >>> >>>> >> >>> >>> >>>> # search [`MAX (SUC m) (SUC n)`];; >> >>> >>> >>>> val it : (string * thm) list = >> >>> >>> >>>> [("MAX_SUC", |- !m n. MAX (SUC m) (SUC n) = SUC (MAX m n))] >> >>> >>> >>>> >> >>> >>> >>>> 3) It looks like you need to extend_the_interpretation before >> >>> >>> >>>> loading >> >>> >>> >>>> the proofs as described in >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> >> >>> >>> >>>> http://www.gilith.com/pipermail/opentheory-users/2015-June/000515.html >> >>> >>> >>>> >> >>> >>> >>>> Cheers, >> >>> >>> >>>> >> >>> >>> >>>> Joe >> >>> >>> >>>> >> >>> >>> >>>> On Wed, Jun 24, 2015 at 1:31 PM, Robert White >> >>> >>> >>>> wrote: >> >>> >>> >>>> > Dear Joe and all, >> >>> >>> >>>> > >> >>> >>> >>>> > I am back to the community! >> >>> >>> >>>> > >> >>> >>> >>>> > I have the following questions and updates for you: >> >>> >>> >>>> > >> >>> >>> >>>> > 1) I will be finishing my internship in a few weeks and it >> >>> >>> >>>> > would >> >>> >>> >>>> > be >> >>> >>> >>>> > nice of >> >>> >>> >>>> > you if you can give me some description of the most recent >> >>> >>> >>>> > updates >> >>> >>> >>>> > of >> >>> >>> >>>> > OpenTheory. >> >>> >>> >>>> > >> >>> >>> >>>> > 2) >> >>> >>> >>>> > I noticed there is a part not imported to Opentheory (in >> >>> >>> >>>> > hol.ml) : >> >>> >>> >>>> > >> >>> >>> >>>> > (* Not yet ported to OpenTheory >> >>> >>> >>>> > loads "calc_int.ml";; (* Calculation with integer-valued >> >>> >>> >>>> > reals >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "realarith.ml";; (* Universal linear real decision >> >>> >>> >>>> > procedure >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "real.ml";; (* Derived properties of reals >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "calc_rat.ml";; (* Calculation with rational-valued >> >>> >>> >>>> > reals >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "int.ml";; (* Definition of integers >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "iterate.ml";; (* Iterated operations >> >>> >>> >>>> > *) >> >>> >>> >>>> > loads "cart.ml";; (* Finite Cartesian products >> >>> >>> >>>> > *) >> >>> >>> >>>> > *) >> >>> >>> >>>> > >> >>> >>> >>>> > Is there any reason why not? >> >>> >>> >>>> > >> >>> >>> >>>> > Also, there is a database.ml file. Shall I ignore that in >> >>> >>> >>>> > OpenTheory >> >>> >>> >>>> > HOL? >> >>> >>> >>>> > (since it is not complete anyway) >> >>> >>> >>>> > >> >>> >>> >>>> > 3) >> >>> >>> >>>> > I have problem loading article files: >> >>> >>> >>>> > >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/stream.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/stream.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line >> >>> >>> >>>> > 1273: defineTypeOp\nstack = [Thm; [\"A\"]; >> >>> >>> >>>> > \"Data.Stream.nth\"; >> >>> >>> >>>> > \"Data.Stream.fromFunction\"; \"Data.Stream.stream\"; Var; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > \"Data.Stream.unfold\"; Var; \"Data.Stream.iterate\"; >> >>> >>> >>>> > \"Data.Stream.replicate\"]\nunknown type operator >> >>> >>> >>>> > \"Data.Stream.stream\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-prime.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-prime.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line 191: const\nstack = [\"Number.Natural.divides\"; Term; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > Term; >> >>> >>> >>>> > Term; >> >>> >>> >>>> > Var; \"Number.Natural.prime\"; Term; Var; [[]; [[Var; >> >>> >>> >>>> > Term]]]; >> >>> >>> >>>> > Thm]\nunknown >> >>> >>> >>>> > constant \"Number.Natural.divides\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > >> >>> >>> >>>> > >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Sys_error >> >>> >>> >>>> > >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divide.art: >> >>> >>> >>>> > No >> >>> >>> >>>> > such >> >>> >>> >>>> > file >> >>> >>> >>>> > or directory". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > >> >>> >>> >>>> > >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-divides.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-divides.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line 159: defineConst\nstack = [Term; >> >>> >>> >>>> > \"Number.Natural.divides\"; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > []]\nunknown constant \"Number.Natural.divides\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/modular.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/modular.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line >> >>> >>> >>>> > 155: const\nstack = [\"Number.Modular.modulus\"; Term; >> >>> >>> >>>> > Term; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > Var; >> >>> >>> >>>> > \"Number.Modular.equivalent\"; Term; Var; Term; Var; []; >> >>> >>> >>>> > \"HOLLight.modular_to_class\"; >> >>> >>> >>>> > \"HOLLight.modular_from_class\"; >> >>> >>> >>>> > \"Number.Modular.modular\"; TypeOp; TypeOp; >> >>> >>> >>>> > Const]\nunknown >> >>> >>> >>>> > constant \"Number.Modular.modulus\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/gfp.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/gfp.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line >> >>> >>> >>>> > 54: >> >>> >>> >>>> > const\nstack = [\"Number.GF(p).oddprime\"; Term; Var; >> >>> >>> >>>> > []]\nunknown >> >>> >>> >>>> > constant >> >>> >>> >>>> > \"Number.GF(p).oddprime\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > >> >>> >>> >>>> > >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/natural-fibonacci.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/natural-fibonacci.art >> >>> >>> >>>> > at line 1933: defineConstList\nstack = [Thm; >> >>> >>> >>>> > [[\"Number.Natural.Fibonacci.zeckendorf\"; Var]]; Var; []; >> >>> >>> >>>> > Thm]\nunknown >> >>> >>> >>>> > constant \"Number.Natural.Fibonacci.zeckendorf\"". >> >>> >>> >>>> > # let p = load_proofs >> >>> >>> >>>> > "/home/robert/Project/laholide/opentheory/word.art";; >> >>> >>> >>>> > Exception: >> >>> >>> >>>> > Failure >> >>> >>> >>>> > "in article >> >>> >>> >>>> > /home/robert/Project/laholide/opentheory/word.art >> >>> >>> >>>> > at >> >>> >>> >>>> > line >> >>> >>> >>>> > 130: >> >>> >>> >>>> > const\nstack = [\"Data.Word.width\"; Term; >> >>> >>> >>>> > \"Data.Word.modulus\"; >> >>> >>> >>>> > Thm; >> >>> >>> >>>> > Thm]\nunknown constant \"Data.Word.width\"". >> >>> >>> >>>> > # >> >>> >>> >>>> > >> >>> >>> >>>> > Could you please help on that? It seems I can't even play >> >>> >>> >>>> > with >> >>> >>> >>>> > the >> >>> >>> >>>> > other >> >>> >>> >>>> > article files I used to be able to load either :( >> >>> >>> >>>> > >> >>> >>> >>>> > Thanks very much! >> >>> >>> >>>> > >> >>> >>> >>>> > -- >> >>> >>> >>>> > >> >>> >>> >>>> > Regards, >> >>> >>> >>>> > Robert White (Shuai Wang) >> >>> >>> >>>> > INRIA Deducteam >> >>> >>> >>>> > [Moving to ILLC of UvA from this Sep to continue my >> >>> >>> >>>> > masters. ] >> >>> >>> >>>> > [New email address will be shuai.wang at student.uva.nl] >> >>> >>> >>>> > >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> >> >>> >>> >>> -- >> >>> >>> >>> >> >>> >>> >>> Regards, >> >>> >>> >>> Robert White (Shuai Wang) >> >>> >>> >>> INRIA Deducteam >> >>> >>> >>> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >>> >>> [New email address will be shuai.wang at student.uva.nl] >> >>> >>> >>> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> >> >>> >>> >> -- >> >>> >>> >> >> >>> >>> >> Regards, >> >>> >>> >> Robert White (Shuai Wang) >> >>> >>> >> INRIA Deducteam >> >>> >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >>> >> [New email address will be shuai.wang at student.uva.nl] >> >>> >>> >> >> >>> >>> > >> >>> >>> > >> >>> >>> > >> >>> >>> > -- >> >>> >>> > >> >>> >>> > Regards, >> >>> >>> > Robert White (Shuai Wang) >> >>> >>> > INRIA Deducteam >> >>> >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >>> > [New email address will be shuai.wang at student.uva.nl] >> >>> >>> > >> >>> >> >> >>> >> >> >>> >> >> >>> >> >> >>> >> -- >> >>> >> >> >>> >> Regards, >> >>> >> Robert White (Shuai Wang) >> >>> >> INRIA Deducteam >> >>> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> >> [New email address will be shuai.wang at student.uva.nl] >> >>> >> >> >>> > >> >>> > >> >>> > >> >>> > -- >> >>> > >> >>> > Regards, >> >>> > Robert White (Shuai Wang) >> >>> > INRIA Deducteam >> >>> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >>> > [New email address will be shuai.wang at student.uva.nl] >> >>> > >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Regards, >> >> Robert White (Shuai Wang) >> >> INRIA Deducteam >> >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >> [New email address will be shuai.wang at student.uva.nl] >> >> >> > >> > >> > >> > -- >> > >> > Regards, >> > Robert White (Shuai Wang) >> > INRIA Deducteam >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> > [New email address will be shuai.wang at student.uva.nl] >> > > > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > From joe at gilith.com Wed Jul 8 15:21:41 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Wed, 8 Jul 2015 08:21:41 -0700 Subject: [opentheory-users] error loading article files (again?). In-Reply-To: <773696E1-502A-4D08-87C2-2D4F1C5B498B@nicta.com.au> References: <29E31D9F-E87D-4779-8683-CAE388F0AE3A@nicta.com.au> <773696E1-502A-4D08-87C2-2D4F1C5B498B@nicta.com.au> Message-ID: Hi Michael, It seems to me for your use-case that the simplest thing might be to choose one of HOL4 and HOL Light as the master namespace, and then convert all names from the other system into it. Alternatively, you could come up with a new standard namespace and convert everything into it. This is the OpenTheory approach, and you can see the resulting mapping for the HOL Light standard theory library in https://github.com/gilith/hol-light/blob/master/opentheory/stdlib/stdlib.int Cheers, Joe On Mon, Jul 6, 2015 at 10:51 PM, Michael Norrish wrote: > That?s a nice explanation; thanks. > > So here?s the next question: how should we best establish a name space for inter-operation between HOL Light and HOL4 that doesn?t use the OpenTheory library, and prefers instead to use sets as predicates? Such a namespace would still have to figure out what to do with numerals, but hey. > > Michael > > >> On 3 Jul 2015, at 01:58, Joe Leslie-Hurd wrote: >> >> Hi Michael, >> >> I think your statement is correct, because both HOL Light and HOL4 use >> predicates rather than an explicit set type, so if OpenTheory also >> used predicates it would simplify translation between these two >> environments. And indeed, it complicates export if an explicit set >> type has to be reconstructed from predicates. >> >> However, one design principle of OpenTheory is that whenever there is >> a trade-off between simplifying import or export then it's better to >> simplify importing, and in this case it's easy to drop the explicit >> set type in favour of predicates during import. >> >> And there are other environments that do implement explicit set types, >> such as Haskell. When exporting theories as Haskell packages I want to >> export explicit sets as Haskell sets, which would be difficult if >> OpenTheory used predicates. >> >> Cheers, >> >> Joe >> >> On Wed, Jul 1, 2015 at 10:38 PM, Michael Norrish >> wrote: >>> >>>> On 2 Jul 2015, at 06:57, Joe Leslie-Hurd wrote: >>> >>>> However, I can answer your question right now. I do want the >>>> OpenTheory fork of HOL Light to be as close as possible to the main >>>> trunk of HOL Light, but there are certain changes that are required to >>>> export a standard theory library (which is the primary purpose of this >>>> fork). For example, introducing an explicit set type (A set) rather >>>> than the predicate (A -> bool) and removing default cases (e.g., PRE 0 >>>> = 0) are necessary to ensure the standard theory library can be used >>>> in as many environments as possible. >>> >>> Is it not now our experience that providing an explicit set type actually makes it *harder* to use OpenTheory in both HOL4 and HOL Light? >>> >>> Michael >>> >>> ________________________________ >>> >>> The information in this e-mail may be confidential and subject to legal professional privilege and/or copyright. National ICT Australia Limited accepts no liability for any damage caused by this email or its attachments. >>> >>> _______________________________________________ >>> 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 ai.robert.wangshuai at gmail.com Thu Jul 9 12:12:24 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Thu, 9 Jul 2015 14:12:24 +0200 Subject: [opentheory-users] What's behind the article merging function Message-ID: Dear Joe, I wonder what's behind OpenTheory when it's merging two or more article files together. Is there any optimization? By the way, for HOL Light, is there any function I can tell which thm is in which article file after exporting? Thanks a lot! -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Jul 9 18:35:37 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 9 Jul 2015 11:35:37 -0700 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Hi Robert, Whenever an article is generated, it is normalized so that if a type or term is used multiple times then it is built once, saved in a dictionary, and then pulled out when needed. For theorems this is taken even further, so that theorems that are alpha-equivalent are only constructed once. I'm afraid there's currently no infrastructure for recording which article file a theorem was exported to in HOL Light. It probably wouldn't be too hard to add, though, if you needed the information. Cheers, Joe On Thu, Jul 9, 2015 at 5:12 AM, Robert White wrote: > Dear Joe, > > I wonder what's behind OpenTheory when it's merging two or more article > files together. Is there any optimization? > > By the way, for HOL Light, is there any function I can tell which thm is in > which article file after exporting? > > > Thanks a lot! > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From ai.robert.wangshuai at gmail.com Fri Jul 10 07:55:43 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Fri, 10 Jul 2015 09:55:43 +0200 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Dear Joe, Thanks for the reply. Yeah, such a function would be helpful Regards Robert On Jul 9, 2015 8:35 PM, "Joe Leslie-Hurd" wrote: > Hi Robert, > > Whenever an article is generated, it is normalized so that if a type > or term is used multiple times then it is built once, saved in a > dictionary, and then pulled out when needed. For theorems this is > taken even further, so that theorems that are alpha-equivalent are > only constructed once. > > I'm afraid there's currently no infrastructure for recording which > article file a theorem was exported to in HOL Light. It probably > wouldn't be too hard to add, though, if you needed the information. > > Cheers, > > Joe > > > On Thu, Jul 9, 2015 at 5:12 AM, Robert White > wrote: > > Dear Joe, > > > > I wonder what's behind OpenTheory when it's merging two or more article > > files together. Is there any optimization? > > > > By the way, for HOL Light, is there any function I can tell which thm is > in > > which article file after exporting? > > > > > > Thanks a lot! > > > > -- > > > > Regards, > > Robert White (Shuai Wang) > > INRIA Deducteam > > [Moving to ILLC of UvA from this Sep to continue my masters. ] > > [New email address will be shuai.wang at student.uva.nl] > > > > > > _______________________________________________ > > 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 Jul 13 21:06:10 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 13 Jul 2015 14:06:10 -0700 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Hi Robert, If you pull the most recent version of the OpenTheory HOL Light fork, you can use list_the_exported_thms ();; to show a list of exported theorems together with the theory they were exported to (i.e., the argument to logfile). Hopefully that's the information you require. Cheers, Joe On Fri, Jul 10, 2015 at 12:55 AM, Robert White wrote: > Dear Joe, > Thanks for the reply. > > Yeah, such a function would be helpful > > Regards > Robert > > On Jul 9, 2015 8:35 PM, "Joe Leslie-Hurd" wrote: >> >> Hi Robert, >> >> Whenever an article is generated, it is normalized so that if a type >> or term is used multiple times then it is built once, saved in a >> dictionary, and then pulled out when needed. For theorems this is >> taken even further, so that theorems that are alpha-equivalent are >> only constructed once. >> >> I'm afraid there's currently no infrastructure for recording which >> article file a theorem was exported to in HOL Light. It probably >> wouldn't be too hard to add, though, if you needed the information. >> >> Cheers, >> >> Joe >> >> >> On Thu, Jul 9, 2015 at 5:12 AM, Robert White >> wrote: >> > Dear Joe, >> > >> > I wonder what's behind OpenTheory when it's merging two or more article >> > files together. Is there any optimization? >> > >> > By the way, for HOL Light, is there any function I can tell which thm is >> > in >> > which article file after exporting? >> > >> > >> > Thanks a lot! >> > >> > -- >> > >> > Regards, >> > Robert White (Shuai Wang) >> > INRIA Deducteam >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> > [New email address will be shuai.wang at student.uva.nl] >> > >> > >> > _______________________________________________ >> > 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 ai.robert.wangshuai at gmail.com Mon Jul 13 21:44:08 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Mon, 13 Jul 2015 23:44:08 +0200 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Thanks a lot Joe, I will merge it up :) Robert On 13 July 2015 at 23:06, Joe Leslie-Hurd wrote: > Hi Robert, > > If you pull the most recent version of the OpenTheory HOL Light fork, > you can use > > list_the_exported_thms ();; > > to show a list of exported theorems together with the theory they were > exported to (i.e., the argument to logfile). > > Hopefully that's the information you require. > > Cheers, > > Joe > > On Fri, Jul 10, 2015 at 12:55 AM, Robert White > wrote: > > Dear Joe, > > Thanks for the reply. > > > > Yeah, such a function would be helpful > > > > Regards > > Robert > > > > On Jul 9, 2015 8:35 PM, "Joe Leslie-Hurd" wrote: > >> > >> Hi Robert, > >> > >> Whenever an article is generated, it is normalized so that if a type > >> or term is used multiple times then it is built once, saved in a > >> dictionary, and then pulled out when needed. For theorems this is > >> taken even further, so that theorems that are alpha-equivalent are > >> only constructed once. > >> > >> I'm afraid there's currently no infrastructure for recording which > >> article file a theorem was exported to in HOL Light. It probably > >> wouldn't be too hard to add, though, if you needed the information. > >> > >> Cheers, > >> > >> Joe > >> > >> > >> On Thu, Jul 9, 2015 at 5:12 AM, Robert White > >> wrote: > >> > Dear Joe, > >> > > >> > I wonder what's behind OpenTheory when it's merging two or more > article > >> > files together. Is there any optimization? > >> > > >> > By the way, for HOL Light, is there any function I can tell which thm > is > >> > in > >> > which article file after exporting? > >> > > >> > > >> > Thanks a lot! > >> > > >> > -- > >> > > >> > Regards, > >> > Robert White (Shuai Wang) > >> > INRIA Deducteam > >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] > >> > [New email address will be shuai.wang at student.uva.nl] > >> > > >> > > >> > _______________________________________________ > >> > 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 > -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From ai.robert.wangshuai at gmail.com Tue Jul 14 11:37:52 2015 From: ai.robert.wangshuai at gmail.com (Robert White) Date: Tue, 14 Jul 2015 13:37:52 +0200 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Dear Joe, Looks like there is again a problem with the number of proofs we have: # List.length (list_the_exported_thms ());; val it : int = 1231 # List.length (search[]);; val it : int = 1686 Could you please update them also? Thanks a lot. Robert On 13 July 2015 at 23:44, Robert White wrote: > Thanks a lot Joe, > > I will merge it up :) > > Robert > > On 13 July 2015 at 23:06, Joe Leslie-Hurd wrote: > >> Hi Robert, >> >> If you pull the most recent version of the OpenTheory HOL Light fork, >> you can use >> >> list_the_exported_thms ();; >> >> to show a list of exported theorems together with the theory they were >> exported to (i.e., the argument to logfile). >> >> Hopefully that's the information you require. >> >> Cheers, >> >> Joe >> >> On Fri, Jul 10, 2015 at 12:55 AM, Robert White >> wrote: >> > Dear Joe, >> > Thanks for the reply. >> > >> > Yeah, such a function would be helpful >> > >> > Regards >> > Robert >> > >> > On Jul 9, 2015 8:35 PM, "Joe Leslie-Hurd" wrote: >> >> >> >> Hi Robert, >> >> >> >> Whenever an article is generated, it is normalized so that if a type >> >> or term is used multiple times then it is built once, saved in a >> >> dictionary, and then pulled out when needed. For theorems this is >> >> taken even further, so that theorems that are alpha-equivalent are >> >> only constructed once. >> >> >> >> I'm afraid there's currently no infrastructure for recording which >> >> article file a theorem was exported to in HOL Light. It probably >> >> wouldn't be too hard to add, though, if you needed the information. >> >> >> >> Cheers, >> >> >> >> Joe >> >> >> >> >> >> On Thu, Jul 9, 2015 at 5:12 AM, Robert White >> >> wrote: >> >> > Dear Joe, >> >> > >> >> > I wonder what's behind OpenTheory when it's merging two or more >> article >> >> > files together. Is there any optimization? >> >> > >> >> > By the way, for HOL Light, is there any function I can tell which >> thm is >> >> > in >> >> > which article file after exporting? >> >> > >> >> > >> >> > Thanks a lot! >> >> > >> >> > -- >> >> > >> >> > Regards, >> >> > Robert White (Shuai Wang) >> >> > INRIA Deducteam >> >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >> >> > [New email address will be shuai.wang at student.uva.nl] >> >> > >> >> > >> >> > _______________________________________________ >> >> > 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 >> > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > > -- Regards, Robert White (Shuai Wang) INRIA Deducteam [Moving to ILLC of UvA from this Sep to continue my masters. ] [New email address will be shuai.wang at student.uva.nl] -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Tue Jul 14 12:55:30 2015 From: joe at gilith.com (Joe Leslie-Hurd) Date: Tue, 14 Jul 2015 05:55:30 -0700 Subject: [opentheory-users] What's behind the article merging function In-Reply-To: References: Message-ID: Hi Robert, On the one hand list_the_exported_thms () is a record of every theorem that was exported to opentheory using an export_thm command. On the other hand search [] is a record of every theorem that was bound to an Ocaml top-level identifier using let thm_name = ...;;; So even though there will be a large overlap between the two, there's really no reason that they should be the same. Cheers, Joe On Tue, Jul 14, 2015 at 4:37 AM, Robert White wrote: > Dear Joe, > > Looks like there is again a problem with the number of proofs we have: > # List.length (list_the_exported_thms ());; > val it : int = 1231 > # List.length (search[]);; > val it : int = 1686 > > Could you please update them also? > Thanks a lot. > Robert > > On 13 July 2015 at 23:44, Robert White > wrote: >> >> Thanks a lot Joe, >> >> I will merge it up :) >> >> Robert >> >> On 13 July 2015 at 23:06, Joe Leslie-Hurd wrote: >>> >>> Hi Robert, >>> >>> If you pull the most recent version of the OpenTheory HOL Light fork, >>> you can use >>> >>> list_the_exported_thms ();; >>> >>> to show a list of exported theorems together with the theory they were >>> exported to (i.e., the argument to logfile). >>> >>> Hopefully that's the information you require. >>> >>> Cheers, >>> >>> Joe >>> >>> On Fri, Jul 10, 2015 at 12:55 AM, Robert White >>> wrote: >>> > Dear Joe, >>> > Thanks for the reply. >>> > >>> > Yeah, such a function would be helpful >>> > >>> > Regards >>> > Robert >>> > >>> > On Jul 9, 2015 8:35 PM, "Joe Leslie-Hurd" wrote: >>> >> >>> >> Hi Robert, >>> >> >>> >> Whenever an article is generated, it is normalized so that if a type >>> >> or term is used multiple times then it is built once, saved in a >>> >> dictionary, and then pulled out when needed. For theorems this is >>> >> taken even further, so that theorems that are alpha-equivalent are >>> >> only constructed once. >>> >> >>> >> I'm afraid there's currently no infrastructure for recording which >>> >> article file a theorem was exported to in HOL Light. It probably >>> >> wouldn't be too hard to add, though, if you needed the information. >>> >> >>> >> Cheers, >>> >> >>> >> Joe >>> >> >>> >> >>> >> On Thu, Jul 9, 2015 at 5:12 AM, Robert White >>> >> wrote: >>> >> > Dear Joe, >>> >> > >>> >> > I wonder what's behind OpenTheory when it's merging two or more >>> >> > article >>> >> > files together. Is there any optimization? >>> >> > >>> >> > By the way, for HOL Light, is there any function I can tell which >>> >> > thm is >>> >> > in >>> >> > which article file after exporting? >>> >> > >>> >> > >>> >> > Thanks a lot! >>> >> > >>> >> > -- >>> >> > >>> >> > Regards, >>> >> > Robert White (Shuai Wang) >>> >> > INRIA Deducteam >>> >> > [Moving to ILLC of UvA from this Sep to continue my masters. ] >>> >> > [New email address will be shuai.wang at student.uva.nl] >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > 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 >> >> >> >> >> -- >> >> Regards, >> Robert White (Shuai Wang) >> INRIA Deducteam >> [Moving to ILLC of UvA from this Sep to continue my masters. ] >> [New email address will be shuai.wang at student.uva.nl] >> > > > > -- > > Regards, > Robert White (Shuai Wang) > INRIA Deducteam > [Moving to ILLC of UvA from this Sep to continue my masters. ] > [New email address will be shuai.wang at student.uva.nl] > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users >