From di.gama at gmail.com Sun Oct 12 02:57:31 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sat, 11 Oct 2014 22:57:31 -0400 Subject: [opentheory-users] Error in 'make' for opentheory Message-ID: Hello, I'm trying to run the opentheory program, and I believe I have correctly installed Poly/ML for compilation on Cygwin in Windows 8. However, it appears to be crashing in the self-test: $ make make[1]: Entering directory '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' +-------------------------------------+ | Build and test the Poly/ML programs | +-------------------------------------+ +---------------------------+ | Compile a Poly/ML program | +---------------------------+ bin/polyml/selftest cd bin/polyml && polyc -o selftest selftest.sml Exception- SysErr ... raised Makefile:270: recipe for target 'bin/polyml/selftest' failed make[1]: *** [bin/polyml/selftest] Error 1 rm bin/polyml/selftest.sml make[1]: Leaving directory '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' Makefile:14: recipe for target 'default' failed make: *** [default] Error 2 Since there isn't any additional information, I'm not sure what about the self-test is causing problems, and in the bin/polyml folder the selftest.sml file that is created is gigantic, 67833 lines, and appears to be the concatenation of all the source files, so I have no idea what is going on or how to diagnose it. Suggestions? Alternatively, is there any other way to download the opentheory files decompiled from HOL Light (which is my actual goal)? There appears to be a repository of such files (http://opentheory.gilith.com/) but it recommends installation of this program in order to do the download and since it's not precompiled this is giving me a lot of trouble. Mario Carneiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Sun Oct 12 09:39:48 2014 From: rda at lemma-one.com (Rob Arthan) Date: Sun, 12 Oct 2014 10:39:48 +0100 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: Message-ID: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Mario, On 12 Oct 2014, at 03:57, Mario Carneiro wrote: > Hello, I'm trying to run the opentheory program, and I believe I have correctly installed Poly/ML for compilation on Cygwin in Windows 8. However, it appears to be crashing in the self-test: > > > $ make > make[1]: Entering directory '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > > +-------------------------------------+ > | Build and test the Poly/ML programs | > +-------------------------------------+ > > > +---------------------------+ > | Compile a Poly/ML program | > +---------------------------+ > > bin/polyml/selftest > cd bin/polyml && polyc -o selftest selftest.sml > Exception- SysErr ... raised > Makefile:270: recipe for target 'bin/polyml/selftest' failed > make[1]: *** [bin/polyml/selftest] Error 1 > rm bin/polyml/selftest.sml > make[1]: Leaving directory '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > Makefile:14: recipe for target 'default' failed > make: *** [default] Error 2 > > > Since there isn't any additional information, I'm not sure what about the self-test is causing problems, and in the bin/polyml folder the selftest.sml file that is created is gigantic, 67833 lines, and appears to be the concatenation of all the source files, so I have no idea what is going on or how to diagnose it. Suggestions? > Try doing: make bin/polyml/selftest.sml to make the big source file, and then poly < bin/polyml/selftest.sml | tee poly.log which will run Poly/ML in its interactive mode. This will list the structures that make up the program as they are compiled and give some idea where the compilation is failing. > Alternatively, is there any other way to download the opentheory files decompiled from HOL Light (which is my actual goal)? There appears to be a repository of such files (http://opentheory.gilith.com/) but it recommends installation of this program in order to do the download and since it's not precompiled this is giving me a lot of trouble. I don?t think the opentheory files will be any use to you without the opentheory program to process them. Regards, Rob. > > Mario Carneiro > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Oct 12 18:14:25 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 12 Oct 2014 11:14:25 -0700 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: Hi Mario, I've just made a new release of the opentheory tool http://www.gilith.com/software/opentheory/download.html that fixes the Poly/ML compile script (I was using polyc, but had left the old export directive in the source). Perhaps that will fix the problem? Unfortunately, I can't test it because I don't have access to a Cygwin setup. In case it doesn't, I ran the command opentheory info --article -o base.art base which exports the standard theory library http://opentheory.gilith.com/?pkg=base as one OpenTheory article file, and the result can be found here: http://www.gilith.com/base.art This may help you evaluate whether OpenTheory will be suitable for your project. Cheers, Joe On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan wrote: > Mario, > > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: > > Hello, I'm trying to run the opentheory program, and I believe I have > correctly installed Poly/ML for compilation on Cygwin in Windows 8. However, > it appears to be crashing in the self-test: > > > $ make > make[1]: Entering directory > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > > +-------------------------------------+ > | Build and test the Poly/ML programs | > +-------------------------------------+ > > > +---------------------------+ > | Compile a Poly/ML program | > +---------------------------+ > > bin/polyml/selftest > cd bin/polyml && polyc -o selftest selftest.sml > Exception- SysErr ... raised > Makefile:270: recipe for target 'bin/polyml/selftest' failed > make[1]: *** [bin/polyml/selftest] Error 1 > rm bin/polyml/selftest.sml > make[1]: Leaving directory > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > Makefile:14: recipe for target 'default' failed > make: *** [default] Error 2 > > > Since there isn't any additional information, I'm not sure what about the > self-test is causing problems, and in the bin/polyml folder the selftest.sml > file that is created is gigantic, 67833 lines, and appears to be the > concatenation of all the source files, so I have no idea what is going on or > how to diagnose it. Suggestions? > > > Try doing: > > make bin/polyml/selftest.sml > > to make the big source file, and then > > poly < bin/polyml/selftest.sml | tee poly.log > > which will run Poly/ML in its interactive mode. > This will list the structures that make up the > program as they are compiled and give some idea > where the compilation is failing. > > Alternatively, is there any other way to download the opentheory files > decompiled from HOL Light (which is my actual goal)? There appears to be a > repository of such files (http://opentheory.gilith.com/) but it recommends > installation of this program in order to do the download and since it's not > precompiled this is giving me a lot of trouble. > > > I don't think the opentheory files will be any use to you > without the opentheory program to process them. > > Regards, > > Rob. > > > Mario Carneiro > _______________________________________________ > 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 Sun Oct 12 18:16:41 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 12 Oct 2014 11:16:41 -0700 Subject: [opentheory-users] Building opentheory with Poly/ML In-Reply-To: <1CC9F4DA-E2ED-46C6-9AE6-6573A4B3F466@lemma-one.com> References: <1CC9F4DA-E2ED-46C6-9AE6-6573A4B3F466@lemma-one.com> Message-ID: Hi Rob, Thanks for this patch - I think the latest version of the opentheory tool is now properly set up with polyc. Cheers, Joe On Sat, May 17, 2014 at 4:11 AM, Rob Arthan wrote: > Dear All, > > David Matthews has just released version 5.5.2 of Poly/ML. This includes a > script called polyc that compiles and links ML programs without you having > to supply linker options that depend on your OS or on where you have > installed Poly/ML. The attached patch to the opentheory Makefile uses polyc > instead of cc to link opentheory and should work with version 5.5.2 and all > future versions of Poly/ML. The unpatched Makefile won't work (with any > version of Poly/ML) unless you have installed Poly/ML where the linker will > find it by default. > > Regards, > > Rob. > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From di.gama at gmail.com Sun Oct 12 20:34:10 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 12 Oct 2014 16:34:10 -0400 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: Hm, it's a little better, but the last lines are val main = fn: unit -> unit and I think that the "main" function is created by the script as well, and is also huge. There is no error message, it just quits after this. Or does that mean it worked? (PS: Poly/ML needs to work on their error reporting.) Mario On Sun, Oct 12, 2014 at 2:14 PM, Joe Leslie-Hurd wrote: > Hi Mario, > > I've just made a new release of the opentheory tool > > http://www.gilith.com/software/opentheory/download.html > > that fixes the Poly/ML compile script (I was using polyc, but had left > the old export directive in the source). Perhaps that will fix the > problem? Unfortunately, I can't test it because I don't have access to > a Cygwin setup. > > In case it doesn't, I ran the command > > opentheory info --article -o base.art base > > which exports the standard theory library > > http://opentheory.gilith.com/?pkg=base > > as one OpenTheory article file, and the result can be found here: > > http://www.gilith.com/base.art > > This may help you evaluate whether OpenTheory will be suitable for your > project. > > Cheers, > > Joe > > On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan wrote: > > Mario, > > > > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: > > > > Hello, I'm trying to run the opentheory program, and I believe I have > > correctly installed Poly/ML for compilation on Cygwin in Windows 8. > However, > > it appears to be crashing in the self-test: > > > > > > $ make > > make[1]: Entering directory > > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > > > > +-------------------------------------+ > > | Build and test the Poly/ML programs | > > +-------------------------------------+ > > > > > > +---------------------------+ > > | Compile a Poly/ML program | > > +---------------------------+ > > > > bin/polyml/selftest > > cd bin/polyml && polyc -o selftest selftest.sml > > Exception- SysErr ... raised > > Makefile:270: recipe for target 'bin/polyml/selftest' failed > > make[1]: *** [bin/polyml/selftest] Error 1 > > rm bin/polyml/selftest.sml > > make[1]: Leaving directory > > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > > Makefile:14: recipe for target 'default' failed > > make: *** [default] Error 2 > > > > > > Since there isn't any additional information, I'm not sure what about the > > self-test is causing problems, and in the bin/polyml folder the > selftest.sml > > file that is created is gigantic, 67833 lines, and appears to be the > > concatenation of all the source files, so I have no idea what is going > on or > > how to diagnose it. Suggestions? > > > > > > Try doing: > > > > make bin/polyml/selftest.sml > > > > to make the big source file, and then > > > > poly < bin/polyml/selftest.sml | tee poly.log > > > > which will run Poly/ML in its interactive mode. > > This will list the structures that make up the > > program as they are compiled and give some idea > > where the compilation is failing. > > > > Alternatively, is there any other way to download the opentheory files > > decompiled from HOL Light (which is my actual goal)? There appears to be > a > > repository of such files (http://opentheory.gilith.com/) but it > recommends > > installation of this program in order to do the download and since it's > not > > precompiled this is giving me a lot of trouble. > > > > > > I don't think the opentheory files will be any use to you > > without the opentheory program to process them. > > > > Regards, > > > > Rob. > > > > > > Mario Carneiro > > _______________________________________________ > > opentheory-users mailing list > > opentheory-users at gilith.com > > http://www.gilith.com/mailman/listinfo/opentheory-users > > > > > > > > _______________________________________________ > > opentheory-users mailing list > > opentheory-users at gilith.com > > http://www.gilith.com/mailman/listinfo/opentheory-users > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: poly.log Type: application/octet-stream Size: 3937 bytes Desc: not available URL: From di.gama at gmail.com Sun Oct 12 22:36:16 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 12 Oct 2014 18:36:16 -0400 Subject: [opentheory-users] Troubleshooting an article reader Message-ID: I'm working on an article reader for Java, and the current error I'm seeing doesn't make sense compared to the spec. That is, my test file, bool-int.art, shouldn't be valid, although I assume it is. The relevant lines from the output are: 877::assume [p] |- p 1447:843,1444:eqMp [(p ==> q)] |- (p = (p /\ q)) 1450:877,1447:eqMp [p, (p ==> q)] |- (p /\ q) 1624:1621:subst [(p /\ q)] |- q 1627:1450,1624:deductAntisym [p, (p ==> q)] |- ((p /\ q) = q) 1630:1450,1627:eqMp [p, (p ==> q)] |- q 9849:698:subst [] |- ((((! \x. ((P x) ==> Q)) /\ ((? P) ==> Q)) = (! \x. ((P x) ==> Q))) = ((! \x. ((P x) ==> Q)) ==> ((? P) ==> Q))) 10205:10187,10204:deductAntisym [] |- (((! \x. ((P x) ==> Q)) /\ ((? P) ==> Q)) = (! \x. ((P x) ==> Q))) 10206:10205,9849:eqMp [] |- ((! \x. ((P x) ==> Q)) ==> ((? P) ==> Q)) 16595:10206:subst [] |- ((! \x. ((P x) ==> Q)) ==> ((? P) ==> Q)) 16959:16595:subst [] |- ((! \x50. ((\y. (x p y) x50) ==> (? \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p y))))) 17006:1630:subst [(! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))), ((! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p y)))))] |- ((? \y. (x p y)) ==> (? \y. (? \x. (x p y)))) 17007:16959,17006:deductAntisym [(! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))), ((! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p y)))))] |- (((! \x50. ((\y. (x p y) x50) ==> (? \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p y))))) = ((? \y. (x p y)) ==> (? \y. (? \x. (x p y))))) (The output format shows all theorem-creating steps, labeled by the line in the file they first appeared, and the theorems they depend on.) I've trimmed the output just to show the direct ancestors of step 17007, which I think is incorrect, because the second hypothesis should have been eliminated but wasn't because the terms \x50. ((\y. (x p y) x50) ==> (? \y. (? \x. (x p y)))) \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y)))) are not alpha-equivalent. The other candidate for the error is step 16959, where we do the substitution P -> \y. (x p y) and Q -> (? \y. (? \x. (x p y))) into \x. ((P x) ==> Q), but since x is bound in the original term and free in P, in accordance with the spec I swap out x -> x50 before doing the substitution. Is this wrong? If there are any readers written in an imperative language, that would also make a good reference. Unfortunately the functional PL examples are different enough in structure that I have difficulty mentally mapping the algorithm from one language to another. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Oct 12 22:42:35 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 12 Oct 2014 15:42:35 -0700 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: Hi Mario, How did you obtain this log? Did you type "make polyml" in the opentheory directory, as per http://www.gilith.com/software/opentheory/install.html This should invoke polyc on the concatenated source code and produce two executables in the bin/polyml directory: selftest and opentheory. It then runs a self-test to make sure everything is working. If anything fails then the "make polyml" command will result in an error, otherwise you should have a working opentheory tool in bin/polyml. Cheers, Joe On Sun, Oct 12, 2014 at 1:34 PM, Mario Carneiro wrote: > Hm, it's a little better, but the last lines are > > val main = fn: unit -> unit > > and I think that the "main" function is created by the script as well, and > is also huge. There is no error message, it just quits after this. Or does > that mean it worked? (PS: Poly/ML needs to work on their error reporting.) > > > > Mario > > > > On Sun, Oct 12, 2014 at 2:14 PM, Joe Leslie-Hurd wrote: >> >> Hi Mario, >> >> I've just made a new release of the opentheory tool >> >> http://www.gilith.com/software/opentheory/download.html >> >> that fixes the Poly/ML compile script (I was using polyc, but had left >> the old export directive in the source). Perhaps that will fix the >> problem? Unfortunately, I can't test it because I don't have access to >> a Cygwin setup. >> >> In case it doesn't, I ran the command >> >> opentheory info --article -o base.art base >> >> which exports the standard theory library >> >> http://opentheory.gilith.com/?pkg=base >> >> as one OpenTheory article file, and the result can be found here: >> >> http://www.gilith.com/base.art >> >> This may help you evaluate whether OpenTheory will be suitable for your >> project. >> >> Cheers, >> >> Joe >> >> On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan wrote: >> > Mario, >> > >> > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: >> > >> > Hello, I'm trying to run the opentheory program, and I believe I have >> > correctly installed Poly/ML for compilation on Cygwin in Windows 8. >> > However, >> > it appears to be crashing in the self-test: >> > >> > >> > $ make >> > make[1]: Entering directory >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >> > >> > +-------------------------------------+ >> > | Build and test the Poly/ML programs | >> > +-------------------------------------+ >> > >> > >> > +---------------------------+ >> > | Compile a Poly/ML program | >> > +---------------------------+ >> > >> > bin/polyml/selftest >> > cd bin/polyml && polyc -o selftest selftest.sml >> > Exception- SysErr ... raised >> > Makefile:270: recipe for target 'bin/polyml/selftest' failed >> > make[1]: *** [bin/polyml/selftest] Error 1 >> > rm bin/polyml/selftest.sml >> > make[1]: Leaving directory >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >> > Makefile:14: recipe for target 'default' failed >> > make: *** [default] Error 2 >> > >> > >> > Since there isn't any additional information, I'm not sure what about >> > the >> > self-test is causing problems, and in the bin/polyml folder the >> > selftest.sml >> > file that is created is gigantic, 67833 lines, and appears to be the >> > concatenation of all the source files, so I have no idea what is going >> > on or >> > how to diagnose it. Suggestions? >> > >> > >> > Try doing: >> > >> > make bin/polyml/selftest.sml >> > >> > to make the big source file, and then >> > >> > poly < bin/polyml/selftest.sml | tee poly.log >> > >> > which will run Poly/ML in its interactive mode. >> > This will list the structures that make up the >> > program as they are compiled and give some idea >> > where the compilation is failing. >> > >> > Alternatively, is there any other way to download the opentheory files >> > decompiled from HOL Light (which is my actual goal)? There appears to be >> > a >> > repository of such files (http://opentheory.gilith.com/) but it >> > recommends >> > installation of this program in order to do the download and since it's >> > not >> > precompiled this is giving me a lot of trouble. >> > >> > >> > I don't think the opentheory files will be any use to you >> > without the opentheory program to process them. >> > >> > Regards, >> > >> > Rob. >> > >> > >> > Mario Carneiro >> > _______________________________________________ >> > opentheory-users mailing list >> > opentheory-users at gilith.com >> > http://www.gilith.com/mailman/listinfo/opentheory-users >> > >> > >> > >> > _______________________________________________ >> > opentheory-users mailing list >> > opentheory-users at gilith.com >> > http://www.gilith.com/mailman/listinfo/opentheory-users >> > >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> >> > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From di.gama at gmail.com Sun Oct 12 22:47:43 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 12 Oct 2014 18:47:43 -0400 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: The log was obtained via your earlier instruction: make bin/polyml/selftest.sml poly < bin/polyml/selftest.sml | tee poly.log Executing "make polyml" yields the error message in the original email, +-------------------------------------+ | Build and test the Poly/ML programs | +-------------------------------------+ +---------------------------+ | Compile a Poly/ML program | +---------------------------+ bin/polyml/selftest cd bin/polyml && polyc -o selftest selftest.sml Exception- SysErr ... raised Makefile:271: recipe for target 'bin/polyml/selftest' failed make: *** [bin/polyml/selftest] Error 1 I'm not sure where the SysErr is coming from, since the other command showed no trace of an exception. The two executables are never created - it fails in the first compilation. On Sun, Oct 12, 2014 at 6:42 PM, Joe Leslie-Hurd wrote: > Hi Mario, > > How did you obtain this log? Did you type "make polyml" in the > opentheory directory, as per > > http://www.gilith.com/software/opentheory/install.html > > This should invoke polyc on the concatenated source code and produce > two executables in the bin/polyml directory: selftest and opentheory. > It then runs a self-test to make sure everything is working. If > anything fails then the "make polyml" command will result in an error, > otherwise you should have a working opentheory tool in bin/polyml. > > Cheers, > > Joe > > On Sun, Oct 12, 2014 at 1:34 PM, Mario Carneiro wrote: > > Hm, it's a little better, but the last lines are > > > > val main = fn: unit -> unit > > > > and I think that the "main" function is created by the script as well, > and > > is also huge. There is no error message, it just quits after this. Or > does > > that mean it worked? (PS: Poly/ML needs to work on their error > reporting.) > > > > > > > > Mario > > > > > > > > On Sun, Oct 12, 2014 at 2:14 PM, Joe Leslie-Hurd wrote: > >> > >> Hi Mario, > >> > >> I've just made a new release of the opentheory tool > >> > >> http://www.gilith.com/software/opentheory/download.html > >> > >> that fixes the Poly/ML compile script (I was using polyc, but had left > >> the old export directive in the source). Perhaps that will fix the > >> problem? Unfortunately, I can't test it because I don't have access to > >> a Cygwin setup. > >> > >> In case it doesn't, I ran the command > >> > >> opentheory info --article -o base.art base > >> > >> which exports the standard theory library > >> > >> http://opentheory.gilith.com/?pkg=base > >> > >> as one OpenTheory article file, and the result can be found here: > >> > >> http://www.gilith.com/base.art > >> > >> This may help you evaluate whether OpenTheory will be suitable for your > >> project. > >> > >> Cheers, > >> > >> Joe > >> > >> On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan wrote: > >> > Mario, > >> > > >> > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: > >> > > >> > Hello, I'm trying to run the opentheory program, and I believe I have > >> > correctly installed Poly/ML for compilation on Cygwin in Windows 8. > >> > However, > >> > it appears to be crashing in the self-test: > >> > > >> > > >> > $ make > >> > make[1]: Entering directory > >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > >> > > >> > +-------------------------------------+ > >> > | Build and test the Poly/ML programs | > >> > +-------------------------------------+ > >> > > >> > > >> > +---------------------------+ > >> > | Compile a Poly/ML program | > >> > +---------------------------+ > >> > > >> > bin/polyml/selftest > >> > cd bin/polyml && polyc -o selftest selftest.sml > >> > Exception- SysErr ... raised > >> > Makefile:270: recipe for target 'bin/polyml/selftest' failed > >> > make[1]: *** [bin/polyml/selftest] Error 1 > >> > rm bin/polyml/selftest.sml > >> > make[1]: Leaving directory > >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' > >> > Makefile:14: recipe for target 'default' failed > >> > make: *** [default] Error 2 > >> > > >> > > >> > Since there isn't any additional information, I'm not sure what about > >> > the > >> > self-test is causing problems, and in the bin/polyml folder the > >> > selftest.sml > >> > file that is created is gigantic, 67833 lines, and appears to be the > >> > concatenation of all the source files, so I have no idea what is going > >> > on or > >> > how to diagnose it. Suggestions? > >> > > >> > > >> > Try doing: > >> > > >> > make bin/polyml/selftest.sml > >> > > >> > to make the big source file, and then > >> > > >> > poly < bin/polyml/selftest.sml | tee poly.log > >> > > >> > which will run Poly/ML in its interactive mode. > >> > This will list the structures that make up the > >> > program as they are compiled and give some idea > >> > where the compilation is failing. > >> > > >> > Alternatively, is there any other way to download the opentheory files > >> > decompiled from HOL Light (which is my actual goal)? There appears to > be > >> > a > >> > repository of such files (http://opentheory.gilith.com/) but it > >> > recommends > >> > installation of this program in order to do the download and since > it's > >> > not > >> > precompiled this is giving me a lot of trouble. > >> > > >> > > >> > I don't think the opentheory files will be any use to you > >> > without the opentheory program to process them. > >> > > >> > Regards, > >> > > >> > Rob. > >> > > >> > > >> > Mario Carneiro > >> > _______________________________________________ > >> > opentheory-users mailing list > >> > opentheory-users at gilith.com > >> > http://www.gilith.com/mailman/listinfo/opentheory-users > >> > > >> > > >> > > >> > _______________________________________________ > >> > opentheory-users mailing list > >> > opentheory-users at gilith.com > >> > http://www.gilith.com/mailman/listinfo/opentheory-users > >> > > >> > >> _______________________________________________ > >> opentheory-users mailing list > >> opentheory-users at gilith.com > >> http://www.gilith.com/mailman/listinfo/opentheory-users > >> > >> > > > > > > _______________________________________________ > > opentheory-users mailing list > > opentheory-users at gilith.com > > http://www.gilith.com/mailman/listinfo/opentheory-users > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Sun Oct 12 23:04:42 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 12 Oct 2014 19:04:42 -0400 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: I just tried running the commands in polyc manually: $ echo "use \"selftest.sml\"; PolyML.export(\"selftest\", main);" | poly -q --error-exit [no errors, selftest.obj created] $ gcc -O3 -I../libffi/include selftest.obj -o selftest -L/usr/local/lib -lpolymain -lpolyml -lgdi32 -lwsock32 -lstdc++ -lgcc_s -lgcc /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ld: cannot find -lpolymain /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ld: cannot find -lpolyml collect2: error: ld returned 1 exit status I'm still trying to figure out what's going on in that last error message, but it might be a Poly/ML configuration problem. On Sun, Oct 12, 2014 at 6:47 PM, Mario Carneiro wrote: > The log was obtained via your earlier instruction: > > make bin/polyml/selftest.sml > poly < bin/polyml/selftest.sml | tee poly.log > > Executing "make polyml" yields the error message in the original email, > > > +-------------------------------------+ > | Build and test the Poly/ML programs | > +-------------------------------------+ > > > +---------------------------+ > | Compile a Poly/ML program | > +---------------------------+ > > bin/polyml/selftest > cd bin/polyml && polyc -o selftest selftest.sml > Exception- SysErr ... raised > Makefile:271: recipe for target 'bin/polyml/selftest' failed > make: *** [bin/polyml/selftest] Error 1 > > > I'm not sure where the SysErr is coming from, since the other command > showed no trace of an exception. The two executables are never created - it > fails in the first compilation. > > On Sun, Oct 12, 2014 at 6:42 PM, Joe Leslie-Hurd wrote: > >> Hi Mario, >> >> How did you obtain this log? Did you type "make polyml" in the >> opentheory directory, as per >> >> http://www.gilith.com/software/opentheory/install.html >> >> This should invoke polyc on the concatenated source code and produce >> two executables in the bin/polyml directory: selftest and opentheory. >> It then runs a self-test to make sure everything is working. If >> anything fails then the "make polyml" command will result in an error, >> otherwise you should have a working opentheory tool in bin/polyml. >> >> Cheers, >> >> Joe >> >> On Sun, Oct 12, 2014 at 1:34 PM, Mario Carneiro >> wrote: >> > Hm, it's a little better, but the last lines are >> > >> > val main = fn: unit -> unit >> > >> > and I think that the "main" function is created by the script as well, >> and >> > is also huge. There is no error message, it just quits after this. Or >> does >> > that mean it worked? (PS: Poly/ML needs to work on their error >> reporting.) >> > >> > >> > >> > Mario >> > >> > >> > >> > On Sun, Oct 12, 2014 at 2:14 PM, Joe Leslie-Hurd >> wrote: >> >> >> >> Hi Mario, >> >> >> >> I've just made a new release of the opentheory tool >> >> >> >> http://www.gilith.com/software/opentheory/download.html >> >> >> >> that fixes the Poly/ML compile script (I was using polyc, but had left >> >> the old export directive in the source). Perhaps that will fix the >> >> problem? Unfortunately, I can't test it because I don't have access to >> >> a Cygwin setup. >> >> >> >> In case it doesn't, I ran the command >> >> >> >> opentheory info --article -o base.art base >> >> >> >> which exports the standard theory library >> >> >> >> http://opentheory.gilith.com/?pkg=base >> >> >> >> as one OpenTheory article file, and the result can be found here: >> >> >> >> http://www.gilith.com/base.art >> >> >> >> This may help you evaluate whether OpenTheory will be suitable for your >> >> project. >> >> >> >> Cheers, >> >> >> >> Joe >> >> >> >> On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan wrote: >> >> > Mario, >> >> > >> >> > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: >> >> > >> >> > Hello, I'm trying to run the opentheory program, and I believe I have >> >> > correctly installed Poly/ML for compilation on Cygwin in Windows 8. >> >> > However, >> >> > it appears to be crashing in the self-test: >> >> > >> >> > >> >> > $ make >> >> > make[1]: Entering directory >> >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >> >> > >> >> > +-------------------------------------+ >> >> > | Build and test the Poly/ML programs | >> >> > +-------------------------------------+ >> >> > >> >> > >> >> > +---------------------------+ >> >> > | Compile a Poly/ML program | >> >> > +---------------------------+ >> >> > >> >> > bin/polyml/selftest >> >> > cd bin/polyml && polyc -o selftest selftest.sml >> >> > Exception- SysErr ... raised >> >> > Makefile:270: recipe for target 'bin/polyml/selftest' failed >> >> > make[1]: *** [bin/polyml/selftest] Error 1 >> >> > rm bin/polyml/selftest.sml >> >> > make[1]: Leaving directory >> >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >> >> > Makefile:14: recipe for target 'default' failed >> >> > make: *** [default] Error 2 >> >> > >> >> > >> >> > Since there isn't any additional information, I'm not sure what about >> >> > the >> >> > self-test is causing problems, and in the bin/polyml folder the >> >> > selftest.sml >> >> > file that is created is gigantic, 67833 lines, and appears to be the >> >> > concatenation of all the source files, so I have no idea what is >> going >> >> > on or >> >> > how to diagnose it. Suggestions? >> >> > >> >> > >> >> > Try doing: >> >> > >> >> > make bin/polyml/selftest.sml >> >> > >> >> > to make the big source file, and then >> >> > >> >> > poly < bin/polyml/selftest.sml | tee poly.log >> >> > >> >> > which will run Poly/ML in its interactive mode. >> >> > This will list the structures that make up the >> >> > program as they are compiled and give some idea >> >> > where the compilation is failing. >> >> > >> >> > Alternatively, is there any other way to download the opentheory >> files >> >> > decompiled from HOL Light (which is my actual goal)? There appears >> to be >> >> > a >> >> > repository of such files (http://opentheory.gilith.com/) but it >> >> > recommends >> >> > installation of this program in order to do the download and since >> it's >> >> > not >> >> > precompiled this is giving me a lot of trouble. >> >> > >> >> > >> >> > I don't think the opentheory files will be any use to you >> >> > without the opentheory program to process them. >> >> > >> >> > Regards, >> >> > >> >> > Rob. >> >> > >> >> > >> >> > Mario Carneiro >> >> > _______________________________________________ >> >> > opentheory-users mailing list >> >> > opentheory-users at gilith.com >> >> > http://www.gilith.com/mailman/listinfo/opentheory-users >> >> > >> >> > >> >> > >> >> > _______________________________________________ >> >> > opentheory-users mailing list >> >> > opentheory-users at gilith.com >> >> > http://www.gilith.com/mailman/listinfo/opentheory-users >> >> > >> >> >> >> _______________________________________________ >> >> opentheory-users mailing list >> >> opentheory-users at gilith.com >> >> http://www.gilith.com/mailman/listinfo/opentheory-users >> >> >> >> >> > >> > >> > _______________________________________________ >> > opentheory-users mailing list >> > opentheory-users at gilith.com >> > http://www.gilith.com/mailman/listinfo/opentheory-users >> > >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Mon Oct 13 01:53:19 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 12 Oct 2014 21:53:19 -0400 Subject: [opentheory-users] Error in 'make' for opentheory In-Reply-To: References: <9493D9C5-5B66-4D40-B008-91AC9D631F14@lemma-one.com> Message-ID: Since this same error is happening for a hello world program, I'm going to try asking the Poly/ML people instead. I'll write back if I have any other issues once this is resolved. On Sun, Oct 12, 2014 at 7:04 PM, Mario Carneiro wrote: > I just tried running the commands in polyc manually: > > $ echo "use \"selftest.sml\"; PolyML.export(\"selftest\", main);" | poly > -q --error-exit > [no errors, selftest.obj created] > $ gcc -O3 -I../libffi/include selftest.obj -o selftest -L/usr/local/lib > -lpolymain -lpolyml -lgdi32 -lwsock32 -lstdc++ -lgcc_s -lgcc > /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ld: > cannot find -lpolymain > /usr/lib/gcc/i686-pc-cygwin/4.8.3/../../../../i686-pc-cygwin/bin/ld: > cannot find -lpolyml > collect2: error: ld returned 1 exit status > > I'm still trying to figure out what's going on in that last error message, > but it might be a Poly/ML configuration problem. > > On Sun, Oct 12, 2014 at 6:47 PM, Mario Carneiro wrote: > >> The log was obtained via your earlier instruction: >> >> make bin/polyml/selftest.sml >> poly < bin/polyml/selftest.sml | tee poly.log >> >> Executing "make polyml" yields the error message in the original email, >> >> >> +-------------------------------------+ >> | Build and test the Poly/ML programs | >> +-------------------------------------+ >> >> >> +---------------------------+ >> | Compile a Poly/ML program | >> +---------------------------+ >> >> bin/polyml/selftest >> cd bin/polyml && polyc -o selftest selftest.sml >> Exception- SysErr ... raised >> Makefile:271: recipe for target 'bin/polyml/selftest' failed >> make: *** [bin/polyml/selftest] Error 1 >> >> >> I'm not sure where the SysErr is coming from, since the other command >> showed no trace of an exception. The two executables are never created - it >> fails in the first compilation. >> >> On Sun, Oct 12, 2014 at 6:42 PM, Joe Leslie-Hurd wrote: >> >>> Hi Mario, >>> >>> How did you obtain this log? Did you type "make polyml" in the >>> opentheory directory, as per >>> >>> http://www.gilith.com/software/opentheory/install.html >>> >>> This should invoke polyc on the concatenated source code and produce >>> two executables in the bin/polyml directory: selftest and opentheory. >>> It then runs a self-test to make sure everything is working. If >>> anything fails then the "make polyml" command will result in an error, >>> otherwise you should have a working opentheory tool in bin/polyml. >>> >>> Cheers, >>> >>> Joe >>> >>> On Sun, Oct 12, 2014 at 1:34 PM, Mario Carneiro >>> wrote: >>> > Hm, it's a little better, but the last lines are >>> > >>> > val main = fn: unit -> unit >>> > >>> > and I think that the "main" function is created by the script as well, >>> and >>> > is also huge. There is no error message, it just quits after this. Or >>> does >>> > that mean it worked? (PS: Poly/ML needs to work on their error >>> reporting.) >>> > >>> > >>> > >>> > Mario >>> > >>> > >>> > >>> > On Sun, Oct 12, 2014 at 2:14 PM, Joe Leslie-Hurd >>> wrote: >>> >> >>> >> Hi Mario, >>> >> >>> >> I've just made a new release of the opentheory tool >>> >> >>> >> http://www.gilith.com/software/opentheory/download.html >>> >> >>> >> that fixes the Poly/ML compile script (I was using polyc, but had left >>> >> the old export directive in the source). Perhaps that will fix the >>> >> problem? Unfortunately, I can't test it because I don't have access to >>> >> a Cygwin setup. >>> >> >>> >> In case it doesn't, I ran the command >>> >> >>> >> opentheory info --article -o base.art base >>> >> >>> >> which exports the standard theory library >>> >> >>> >> http://opentheory.gilith.com/?pkg=base >>> >> >>> >> as one OpenTheory article file, and the result can be found here: >>> >> >>> >> http://www.gilith.com/base.art >>> >> >>> >> This may help you evaluate whether OpenTheory will be suitable for >>> your >>> >> project. >>> >> >>> >> Cheers, >>> >> >>> >> Joe >>> >> >>> >> On Sun, Oct 12, 2014 at 2:39 AM, Rob Arthan >>> wrote: >>> >> > Mario, >>> >> > >>> >> > On 12 Oct 2014, at 03:57, Mario Carneiro wrote: >>> >> > >>> >> > Hello, I'm trying to run the opentheory program, and I believe I >>> have >>> >> > correctly installed Poly/ML for compilation on Cygwin in Windows 8. >>> >> > However, >>> >> > it appears to be crashing in the self-test: >>> >> > >>> >> > >>> >> > $ make >>> >> > make[1]: Entering directory >>> >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >>> >> > >>> >> > +-------------------------------------+ >>> >> > | Build and test the Poly/ML programs | >>> >> > +-------------------------------------+ >>> >> > >>> >> > >>> >> > +---------------------------+ >>> >> > | Compile a Poly/ML program | >>> >> > +---------------------------+ >>> >> > >>> >> > bin/polyml/selftest >>> >> > cd bin/polyml && polyc -o selftest selftest.sml >>> >> > Exception- SysErr ... raised >>> >> > Makefile:270: recipe for target 'bin/polyml/selftest' failed >>> >> > make[1]: *** [bin/polyml/selftest] Error 1 >>> >> > rm bin/polyml/selftest.sml >>> >> > make[1]: Leaving directory >>> >> > '/cygdrive/c/Users/Mario/Documents/hol-light/ot/opentheory' >>> >> > Makefile:14: recipe for target 'default' failed >>> >> > make: *** [default] Error 2 >>> >> > >>> >> > >>> >> > Since there isn't any additional information, I'm not sure what >>> about >>> >> > the >>> >> > self-test is causing problems, and in the bin/polyml folder the >>> >> > selftest.sml >>> >> > file that is created is gigantic, 67833 lines, and appears to be the >>> >> > concatenation of all the source files, so I have no idea what is >>> going >>> >> > on or >>> >> > how to diagnose it. Suggestions? >>> >> > >>> >> > >>> >> > Try doing: >>> >> > >>> >> > make bin/polyml/selftest.sml >>> >> > >>> >> > to make the big source file, and then >>> >> > >>> >> > poly < bin/polyml/selftest.sml | tee poly.log >>> >> > >>> >> > which will run Poly/ML in its interactive mode. >>> >> > This will list the structures that make up the >>> >> > program as they are compiled and give some idea >>> >> > where the compilation is failing. >>> >> > >>> >> > Alternatively, is there any other way to download the opentheory >>> files >>> >> > decompiled from HOL Light (which is my actual goal)? There appears >>> to be >>> >> > a >>> >> > repository of such files (http://opentheory.gilith.com/) but it >>> >> > recommends >>> >> > installation of this program in order to do the download and since >>> it's >>> >> > not >>> >> > precompiled this is giving me a lot of trouble. >>> >> > >>> >> > >>> >> > I don't think the opentheory files will be any use to you >>> >> > without the opentheory program to process them. >>> >> > >>> >> > Regards, >>> >> > >>> >> > Rob. >>> >> > >>> >> > >>> >> > Mario Carneiro >>> >> > _______________________________________________ >>> >> > opentheory-users mailing list >>> >> > opentheory-users at gilith.com >>> >> > http://www.gilith.com/mailman/listinfo/opentheory-users >>> >> > >>> >> > >>> >> > >>> >> > _______________________________________________ >>> >> > opentheory-users mailing list >>> >> > opentheory-users at gilith.com >>> >> > http://www.gilith.com/mailman/listinfo/opentheory-users >>> >> > >>> >> >>> >> _______________________________________________ >>> >> opentheory-users mailing list >>> >> opentheory-users at gilith.com >>> >> http://www.gilith.com/mailman/listinfo/opentheory-users >>> >> >>> >> >>> > >>> > >>> > _______________________________________________ >>> > opentheory-users mailing list >>> > opentheory-users at gilith.com >>> > http://www.gilith.com/mailman/listinfo/opentheory-users >>> > >>> >>> _______________________________________________ >>> opentheory-users mailing list >>> opentheory-users at gilith.com >>> http://www.gilith.com/mailman/listinfo/opentheory-users >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Mon Oct 13 04:51:26 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sun, 12 Oct 2014 21:51:26 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: Hi Mario, I've implemented the "debug" pragma of the article version 6 draft standard http://www.gilith.com/research/opentheory/article.html#pragmaCommand in the opentheory tool, which allowed me to insert "debug" pragma at the lines indicated by your output and compare the two implementations. Let's begin with the subst command on line 16959. Before it executes the opentheory stack looks like this: [|- (!x. P x ==> Q) ==> (?) P ==> Q, [[], [[P, \y. p x y], [Q, ?y x. p x y]]], |- !y. (let y <- y in p x y) ==> ?y x. p x y, ... and afterwards it looks like [|- (!x. (let y <- x in p x y) ==> ?y x. p x y) ==> (?y. p x y) ==> ?y x. p x y, ... This looks pretty bad, because it seems like the variable x has got captured. But if you give the opentheory tool the global option --show-var-types it will annotate every term variable with its type, and now the before stack is [|- (!(x : B). (P : B -> bool) (x : B) ==> (Q : bool)) ==> (?) (P : B -> bool) ==> (Q : bool), [[], [[(P : B -> bool), \(y : B). (p : A -> B -> bool) (x : A) (y : B)], [(Q : bool), ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)]]], ... and the after stack is [|- (!(x : B). (let (y : B) <- (x : B) in (p : A -> B -> bool) (x : A) (y : B)) ==> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)) ==> (?(y : B). (p : A -> B -> bool) (x : A) (y : B)) ==> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B), ... which makes it clear that there are two variables with name "x" but having different types, which according to the rules of higher order logic makes them distinct. The article standard contains the words "Variables are identified by name and type." but should probably make this point far more explicit. Anyway, your reader's strategy of renaming the bound variable to a new name is safe (if not necessary in this case) and so it doesn't solve your problem. In case it helps, here the typed result of the deductAntisym on line 17007 according to the opentheory tool: {!(x : B). (let (y : B) <- (x : B) in (p : A -> B -> bool) (x : A) (y : B)) ==> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)} I'm afraid I can't help you any further without more information: I hope you're able to compile the opentheory tool soon so you can use these new debug pragmas to help identify where your reader is diverging. As to your last question, the only article readers I know of have been implemented in Standard ML, Ocaml and Haskell, so there is no imperative reference available. Perhaps you are writing one! Cheers, Joe On Sun, Oct 12, 2014 at 3:36 PM, Mario Carneiro wrote: > I'm working on an article reader for Java, and the current error I'm seeing > doesn't make sense compared to the spec. That is, my test file, > bool-int.art, shouldn't be valid, although I assume it is. The relevant > lines from the output are: > > 877::assume [p] |- p > 1447:843,1444:eqMp [(p ==> q)] |- (p = (p /\ q)) > 1450:877,1447:eqMp [p, (p ==> q)] |- (p /\ q) > 1624:1621:subst [(p /\ q)] |- q > 1627:1450,1624:deductAntisym [p, (p ==> q)] |- ((p /\ q) = q) > 1630:1450,1627:eqMp [p, (p ==> q)] |- q > 9849:698:subst [] |- ((((! \x. ((P x) ==> Q)) /\ ((? P) ==> > Q)) = (! \x. ((P x) ==> Q))) = ((! \x. ((P x) ==> Q)) ==> ((? P) ==> Q))) > 10205:10187,10204:deductAntisym [] |- (((! \x. ((P x) ==> Q)) /\ ((? P) ==> > Q)) = (! \x. ((P x) ==> Q))) > 10206:10205,9849:eqMp [] |- ((! \x. ((P x) ==> Q)) ==> ((? P) ==> > Q)) > 16595:10206:subst [] |- ((! \x. ((P x) ==> Q)) ==> ((? P) ==> > Q)) > 16959:16595:subst [] |- ((! \x50. ((\y. (x p y) x50) ==> (? > \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p y))))) > 17006:1630:subst [(! \x. ((\y. (x p y) x) ==> (? \y. (? \x. > (x p y))))), ((! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))) ==> ((? > \y. (x p y)) ==> (? \y. (? \x. (x p y)))))] |- ((? \y. (x p y)) ==> (? \y. > (? \x. (x p y)))) > 17007:16959,17006:deductAntisym [(! \x. ((\y. (x p y) x) ==> (? \y. (? \x. > (x p y))))), ((! \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y))))) ==> ((? > \y. (x p y)) ==> (? \y. (? \x. (x p y)))))] |- (((! \x50. ((\y. (x p y) x50) > ==> (? \y. (? \x. (x p y))))) ==> ((? \y. (x p y)) ==> (? \y. (? \x. (x p > y))))) = ((? \y. (x p y)) ==> (? \y. (? \x. (x p y))))) > > (The output format shows all theorem-creating steps, labeled by the line in > the file they first appeared, and the theorems they depend on.) I've trimmed > the output just to show the direct ancestors of step 17007, which I think is > incorrect, because the second hypothesis should have been eliminated but > wasn't because the terms > > \x50. ((\y. (x p y) x50) ==> (? \y. (? \x. (x p y)))) > \x. ((\y. (x p y) x) ==> (? \y. (? \x. (x p y)))) > > are not alpha-equivalent. The other candidate for the error is step 16959, > where we do the substitution P -> \y. (x p y) and Q -> (? \y. (? \x. (x p > y))) into \x. ((P x) ==> Q), but since x is bound in the original term and > free in P, in accordance with the spec I swap out x -> x50 before doing the > substitution. Is this wrong? > > If there are any readers written in an imperative language, that would also > make a good reference. Unfortunately the functional PL examples are > different enough in structure that I have difficulty mentally mapping the > algorithm from one language to another. > > Mario > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From di.gama at gmail.com Mon Oct 13 05:40:56 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 13 Oct 2014 01:40:56 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: On Mon, Oct 13, 2014 at 12:51 AM, Joe Leslie-Hurd wrote: > This looks pretty bad, because it seems like the variable x has got > captured. But if you give the opentheory tool the global option > --show-var-types it will annotate every term variable with its type, > and now the before stack is > > [|- (!(x : B). (P : B -> bool) (x : B) ==> (Q : bool)) ==> > (?) (P : B -> bool) ==> (Q : bool), > [[], > [[(P : B -> bool), \(y : B). (p : A -> B -> bool) (x : A) (y : B)], > [(Q : bool), > ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)]]], ... > > and the after stack is > > [|- (!(x : B). > (let (y : B) <- (x : B) in > (p : A -> B -> bool) (x : A) (y : B)) ==> > ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)) ==> > (?(y : B). (p : A -> B -> bool) (x : A) (y : B)) ==> > ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B), ... > > which makes it clear that there are two variables with name "x" but > having different types, which according to the rules of higher order > logic makes them distinct. The article standard contains the words > > "Variables are identified by name and type." > > but should probably make this point far more explicit. > > Anyway, your reader's strategy of renaming the bound variable to a new > name is safe (if not necessary in this case) and so it doesn't solve > your problem. > Actually, you put your finger right on the issue. I tried changing equality for Vars so that it checks both name and type, instead of just name, and now it rips through the whole file without error. I think the error lies not in this part, since the dummy rename isn't important, but rather later when the inner x in \x. ((\y. (x p y) x) is identified as bound instead of free, which then causes problems in the alpha-equivalence. > As to your last question, the only article readers I know of have been > implemented in Standard ML, Ocaml and Haskell, so there is no > imperative reference available. Perhaps you are writing one! > I intend to write a translator from OpenTheory to Metamath [ http://us.metamath.org/index.html]. Although the main theorem collection is based on and FOL+ZFC foundation, the basic language supports arbitrary syntax, and I've drafted an axiom set that appears to be sufficient to model HOL (based on HOL Light's axioms). However, Metamath does not support proper substitution but rather a form of direct substitution coupled with distinct variable conditions on the substitutions (meaning that even bound occurrences are not allowed). This makes the implementation much simpler, and it's surprisingly effective at being able to model all the details of proper substitution by recursing through equality theorems. Anyway, there are various nontrivial details to be dealt with, but I'll definitely keep you informed if I am successful. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Mon Oct 13 06:11:53 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 13 Oct 2014 02:11:53 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: One thing that is not well explained in the spec is the definition of alpha-equivalent, even though it is used several times. (I'd also like the note "Bound variables will be renamed if necessary to prevent distinct variables becoming identical after the instantiation" in subst to be explained a little more explicitly. Which variables are to be considered distinct?) Can free variables be renamed in an alpha-equivalence? My current implementation says no, and so the following terms: [] |- ((\b. b x217) = ((one_REP (one_ABS x217)) = x217)) [] |- (((\x219. x219 r) = ((one_REP (one_ABS r)) = r)) = ...) should not be considered alpha-equivalent in this application of eqMp because the variable substitution x217 -> r necessary involves a free variable (there are no issues with b -> x219). (FYI this is an error I just got in base.art line 64411, but don't feel obligated to track that down.) If I were manually coding this article file, I'm not sure how I would resolve the issue, since I don't know the name of the dummy x217 so that I could subst it for r, and I can't apply absThm either since it also needs the name of the dummy. Note that this dummy x217 was created by defineTypeOp since there are two names there, r and a, which are not in the stack input. Is that supposed to be a literal "r"? (In metamath, all dummy variable names are specified by the stack machine when they are created, so this issue of "unknown dummies" doesn't occur.) One last question: There are a few constants that appear to be hardcoded into the implementation, in particular "bool", "->" and "=", which are used by commands assume, appThm, refl, respectively (and also "a", "r" in case I guessed correctly in the previous paragraph). This causes conflicts if the constant names for these objects are different in the article file, for example in article files from HOL light where they have names like "HOLLight.=" and "HOLLight.fun". How do you handle these differences in your implementation? The spec doesn't seem to define these constants unambiguously, but I don't see how you could write an implementation that is not sensitive to local differences with these constants. On Mon, Oct 13, 2014 at 1:40 AM, Mario Carneiro wrote: > On Mon, Oct 13, 2014 at 12:51 AM, Joe Leslie-Hurd wrote: > >> This looks pretty bad, because it seems like the variable x has got >> captured. But if you give the opentheory tool the global option >> --show-var-types it will annotate every term variable with its type, >> and now the before stack is >> >> [|- (!(x : B). (P : B -> bool) (x : B) ==> (Q : bool)) ==> >> (?) (P : B -> bool) ==> (Q : bool), >> [[], >> [[(P : B -> bool), \(y : B). (p : A -> B -> bool) (x : A) (y : B)], >> [(Q : bool), >> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)]]], ... >> >> and the after stack is >> >> [|- (!(x : B). >> (let (y : B) <- (x : B) in >> (p : A -> B -> bool) (x : A) (y : B)) ==> >> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)) ==> >> (?(y : B). (p : A -> B -> bool) (x : A) (y : B)) ==> >> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B), ... >> >> which makes it clear that there are two variables with name "x" but >> having different types, which according to the rules of higher order >> logic makes them distinct. The article standard contains the words >> >> "Variables are identified by name and type." >> >> but should probably make this point far more explicit. >> >> Anyway, your reader's strategy of renaming the bound variable to a new >> name is safe (if not necessary in this case) and so it doesn't solve >> your problem. >> > > Actually, you put your finger right on the issue. I tried changing > equality for Vars so that it checks both name and type, instead of just > name, and now it rips through the whole file without error. I think the > error lies not in this part, since the dummy rename isn't important, but > rather later when the inner x in \x. ((\y. (x p y) x) is identified as > bound instead of free, which then causes problems in the alpha-equivalence. > > >> As to your last question, the only article readers I know of have been >> implemented in Standard ML, Ocaml and Haskell, so there is no >> imperative reference available. Perhaps you are writing one! >> > > I intend to write a translator from OpenTheory to Metamath [ > http://us.metamath.org/index.html]. Although the main theorem collection > is based on and FOL+ZFC foundation, the basic language supports arbitrary > syntax, and I've drafted an axiom set that appears to be sufficient to > model HOL (based on HOL Light's axioms). However, Metamath does not support > proper substitution but rather a form of direct substitution coupled with > distinct variable conditions on the substitutions (meaning that even bound > occurrences are not allowed). This makes the implementation much simpler, > and it's surprisingly effective at being able to model all the details of > proper substitution by recursing through equality theorems. Anyway, there > are various nontrivial details to be dealt with, but I'll definitely keep > you informed if I am successful. > > Mario > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Mon Oct 13 09:57:36 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Mon, 13 Oct 2014 10:57:36 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: On Mon, Oct 13, 2014 at 7:11 AM, Mario Carneiro wrote: > One thing that is not well explained in the spec is the definition of > alpha-equivalent, even though it is used several times. (I'd also like the > note "Bound variables will be renamed if necessary to prevent distinct > variables becoming identical after the instantiation" in subst to be > explained a little more explicitly. Which variables are to be considered > distinct?) Can free variables be renamed in an alpha-equivalence? > Terms are alpha-equivalent if they are equal up to a consistent renaming of bound variables. If variable binding is understood, alpha-equivalence is trivial. (Indeed in nameless term representations, like de Bruijn's, alpha-equivalence is the same as equality.) However, variable binding always feels just slightly more complicated than one would like. An unambiguous operational specification of alpha-equivalence can be found in the Model/syntax.ml in the HOL Light distribution (see the definition of ACONV). Alternatively, see my extended port of that formalisation: https://github.com/CakeML/cakeml/blob/master/hol-light/standard/syntax/holSyntaxScript.sml#L78 https://github.com/CakeML/cakeml/blob/master/hol-light/syntax-lib/holSyntaxLibScript.sml#L41 Terms that differ at free variables cannot be alpha-equivalent. My current implementation says no, and so the following terms: > > [] |- ((\b. b x217) = ((one_REP (one_ABS x217)) = x217)) > [] |- (((\x219. x219 r) = ((one_REP (one_ABS r)) = r)) = ...) > > should not be considered alpha-equivalent in this application of eqMp > because the variable substitution x217 -> r necessary involves a free > variable (there are no issues with b -> x219). (FYI this is an error I just > got in base.art line 64411, but don't feel obligated to track that down.) > That sounds correct. > If I were manually coding this article file, I'm not sure how I would > resolve the issue, since I don't know the name of the dummy x217 so that I > could subst it for r, and I can't apply absThm either since it also needs > the name of the dummy. Note that this dummy x217 was created by > defineTypeOp since there are two names there, r and a, which are not in the > stack input. Is that supposed to be a literal "r"? (In metamath, all dummy > variable names are specified by the stack machine when they are created, so > this issue of "unknown dummies" doesn't occur.) > I'm not sure I understand what you mean here. Is the problem that you can't see the type of x217? > > One last question: There are a few constants that appear to be hardcoded > into the implementation, in particular "bool", "->" and "=", which are used > by commands assume, appThm, refl, respectively (and also "a", "r" in case I > guessed correctly in the previous paragraph). > These type operators and constant are primitive in the HOL inference system. > This causes conflicts if the constant names for these objects are > different in the article file, for example in article files from HOL light > where they have names like "HOLLight.=" and "HOLLight.fun". How do you > handle these differences in your implementation? The spec doesn't seem to > define these constants unambiguously, but I don't see how you could write > an implementation that is not sensitive to local differences with these > constants. > I think Joe uses the notion of a theory interpretation to map constants in the HOLLight namespace to the correct OpenTheory namespace. He can probably explain in more detail. > > On Mon, Oct 13, 2014 at 1:40 AM, Mario Carneiro wrote: > >> On Mon, Oct 13, 2014 at 12:51 AM, Joe Leslie-Hurd wrote: >> >>> This looks pretty bad, because it seems like the variable x has got >>> captured. But if you give the opentheory tool the global option >>> --show-var-types it will annotate every term variable with its type, >>> and now the before stack is >>> >>> [|- (!(x : B). (P : B -> bool) (x : B) ==> (Q : bool)) ==> >>> (?) (P : B -> bool) ==> (Q : bool), >>> [[], >>> [[(P : B -> bool), \(y : B). (p : A -> B -> bool) (x : A) (y : B)], >>> [(Q : bool), >>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)]]], ... >>> >>> and the after stack is >>> >>> [|- (!(x : B). >>> (let (y : B) <- (x : B) in >>> (p : A -> B -> bool) (x : A) (y : B)) ==> >>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)) ==> >>> (?(y : B). (p : A -> B -> bool) (x : A) (y : B)) ==> >>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B), ... >>> >>> which makes it clear that there are two variables with name "x" but >>> having different types, which according to the rules of higher order >>> logic makes them distinct. The article standard contains the words >>> >>> "Variables are identified by name and type." >>> >>> but should probably make this point far more explicit. >>> >>> Anyway, your reader's strategy of renaming the bound variable to a new >>> name is safe (if not necessary in this case) and so it doesn't solve >>> your problem. >>> >> >> Actually, you put your finger right on the issue. I tried changing >> equality for Vars so that it checks both name and type, instead of just >> name, and now it rips through the whole file without error. I think the >> error lies not in this part, since the dummy rename isn't important, but >> rather later when the inner x in \x. ((\y. (x p y) x) is identified as >> bound instead of free, which then causes problems in the alpha-equivalence. >> >> >>> As to your last question, the only article readers I know of have been >>> implemented in Standard ML, Ocaml and Haskell, so there is no >>> imperative reference available. Perhaps you are writing one! >>> >> >> I intend to write a translator from OpenTheory to Metamath [ >> http://us.metamath.org/index.html]. Although the main theorem collection >> is based on and FOL+ZFC foundation, the basic language supports arbitrary >> syntax, and I've drafted an axiom set that appears to be sufficient to >> model HOL (based on HOL Light's axioms). However, Metamath does not support >> proper substitution but rather a form of direct substitution coupled with >> distinct variable conditions on the substitutions (meaning that even bound >> occurrences are not allowed). This makes the implementation much simpler, >> and it's surprisingly effective at being able to model all the details of >> proper substitution by recursing through equality theorems. Anyway, there >> are various nontrivial details to be dealt with, but I'll definitely keep >> you informed if I am successful. >> >> Mario >> > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Mon Oct 13 12:10:37 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 13 Oct 2014 08:10:37 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: > If I were manually coding this article file, I'm not sure how I would >> resolve the issue, since I don't know the name of the dummy x217 so that I >> could subst it for r, and I can't apply absThm either since it also needs >> the name of the dummy. Note that this dummy x217 was created by >> defineTypeOp since there are two names there, r and a, which are not in the >> stack input. Is that supposed to be a literal "r"? (In metamath, all dummy >> variable names are specified by the stack machine when they are created, so >> this issue of "unknown dummies" doesn't occur.) >> > > I'm not sure I understand what you mean here. Is the problem that you > can't see the type of x217? > I mean that any formula with a free dummy variable is effectively unusable, because you need to know the name of the variable in order to substitute it away. (Presumably, you already know the type, since it's easy to predict the forms of theorems that are generated.) For example, suppose you know that the formula [] |- x1 = x1 was derived and is on the stack, but x1 is a dummy variable created on a whim by the virtual machine, so you don't at that point in the file know the particular string "x1". You can't bind it, because going from that to [] |- \x1. x1 = \x1. x1 requires absThm with x1 as parameter. You can't substitute it to a known variable a, because going from that to [] |- a = a requires subst with [[],[[x1,a]]] as parameter. And you can't export a theorem and specify the form [] |- a = a, because that's not alpha-equivalent. The only conclusion I can draw is that dummy variables should never be generated in a formula where they would appear free, since there are no means to eliminate them. I'm surprised, then, that a and r aren't quantified in the outputs to defineTypeOp, because if they were you could use dummy variables rather than hardcoding the strings "a" and "r" into the implementation. I think Joe uses the notion of a theory interpretation to map constants in > the HOLLight namespace to the correct OpenTheory namespace. He can probably > explain in more detail. > Ah, just read the theory file spec; I see what you mean about "interpretations". It still seems like an article file that doesn't use the "standard" names for the primitives wouldn't compile, though. To take a simple example, suppose I construct the term (f:(A->B) x:A) in a "non-standard" article file. The final appTerm command has to check that f has the exact type TypeOp(->)[A, B] (or something like it), where the "->" is hardcoded into the reader, i.e. it is the "standard" name ([],"->"). However, the term f:(A->B) was built manually earlier in the article, via a sequence of commands like varTerm(var(f,opType(typeOp(name(["HOLLight"],"fun")),[A,B]))) where the name(["HOLLight"],"fun") is *not* hardcoded and instead is in the article file. This will cause an error in appTerm unless the article file used "->" for its function application operator. In other words a HOL light article should not be able to compile on its own, unless the reader also had name(["HOLLight"],"fun") hardcoded - I would expect a mapping like this to be done during the conversion process, before it makes it into the .art file, if indeed the name "->" is required by spec. FYI I fixed my Poly/ML problem, and now opentheory works like a charm :) Mario > > >> >> On Mon, Oct 13, 2014 at 1:40 AM, Mario Carneiro >> wrote: >> >>> On Mon, Oct 13, 2014 at 12:51 AM, Joe Leslie-Hurd >>> wrote: >>> >>>> This looks pretty bad, because it seems like the variable x has got >>>> captured. But if you give the opentheory tool the global option >>>> --show-var-types it will annotate every term variable with its type, >>>> and now the before stack is >>>> >>>> [|- (!(x : B). (P : B -> bool) (x : B) ==> (Q : bool)) ==> >>>> (?) (P : B -> bool) ==> (Q : bool), >>>> [[], >>>> [[(P : B -> bool), \(y : B). (p : A -> B -> bool) (x : A) (y : >>>> B)], >>>> [(Q : bool), >>>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)]]], ... >>>> >>>> and the after stack is >>>> >>>> [|- (!(x : B). >>>> (let (y : B) <- (x : B) in >>>> (p : A -> B -> bool) (x : A) (y : B)) ==> >>>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B)) ==> >>>> (?(y : B). (p : A -> B -> bool) (x : A) (y : B)) ==> >>>> ?(y : B) (x : A). (p : A -> B -> bool) (x : A) (y : B), ... >>>> >>>> which makes it clear that there are two variables with name "x" but >>>> having different types, which according to the rules of higher order >>>> logic makes them distinct. The article standard contains the words >>>> >>>> "Variables are identified by name and type." >>>> >>>> but should probably make this point far more explicit. >>>> >>>> Anyway, your reader's strategy of renaming the bound variable to a new >>>> name is safe (if not necessary in this case) and so it doesn't solve >>>> your problem. >>>> >>> >>> Actually, you put your finger right on the issue. I tried changing >>> equality for Vars so that it checks both name and type, instead of just >>> name, and now it rips through the whole file without error. I think the >>> error lies not in this part, since the dummy rename isn't important, but >>> rather later when the inner x in \x. ((\y. (x p y) x) is identified as >>> bound instead of free, which then causes problems in the alpha-equivalence. >>> >>> >>>> As to your last question, the only article readers I know of have been >>>> implemented in Standard ML, Ocaml and Haskell, so there is no >>>> imperative reference available. Perhaps you are writing one! >>>> >>> >>> I intend to write a translator from OpenTheory to Metamath [ >>> http://us.metamath.org/index.html]. Although the main theorem >>> collection is based on and FOL+ZFC foundation, the basic language supports >>> arbitrary syntax, and I've drafted an axiom set that appears to be >>> sufficient to model HOL (based on HOL Light's axioms). However, Metamath >>> does not support proper substitution but rather a form of direct >>> substitution coupled with distinct variable conditions on the substitutions >>> (meaning that even bound occurrences are not allowed). This makes the >>> implementation much simpler, and it's surprisingly effective at being able >>> to model all the details of proper substitution by recursing through >>> equality theorems. Anyway, there are various nontrivial details to be dealt >>> with, but I'll definitely keep you informed if I am successful. >>> >>> Mario >>> >> >> >> _______________________________________________ >> 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 Oct 13 15:42:51 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 13 Oct 2014 08:42:51 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: Hi Mario, > One thing that is not well explained in the spec is the definition of > alpha-equivalent, even though it is used several times. Thanks for the feedback. I've added Ramana's one-sentence description of alpha-equivalence (with an example and a non-example) to the description of the term type near the top of http://www.gilith.com/research/opentheory/article.html I also added an example of distinct variables with the same name, following our discussion yesterday. >> I intend to write a translator from OpenTheory to Metamath >> [http://us.metamath.org/index.html]. That sounds really interesting, especially the difference in the substitution primitives. I look forward to hearing more about it. Cheers, Joe From joe at gilith.com Mon Oct 13 15:54:37 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 13 Oct 2014 08:54:37 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: Hi Mario, > The only > conclusion I can draw is that dummy variables should never be generated in a > formula where they would appear free, since there are no means to eliminate > them. I'm surprised, then, that a and r aren't quantified in the outputs to > defineTypeOp, because if they were you could use dummy variables rather than > hardcoding the strings "a" and "r" into the implementation. I agree with your assessment that dummy free variables are a scourge, and therefore in version 6 of the article standard I propose changing the behaviour of defineTypeOp to take the names of the "a" and "r" variables as additional arguments: http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand The nice thing is that literally any variable name will work, because the two resulting theorems of defineTypeOp each have precisely one free variable, so there's nothing to clash with. It's easy to recover the legacy version 5 behaviour by simply passing in the names "a" and "r". Does that satisfy your concerns? I believe that's the only instance in the spec of dummy free variables, but please let me know if that's not the case. > Ah, just read the theory file spec; I see what you mean about > "interpretations". It still seems like an article file that doesn't use the > "standard" names for the primitives wouldn't compile, though. You are correct, see the example package http://www.gilith.com/research/opentheory/example-1.0.html for a description of the external type operators, constants (and axioms) that are treated as primitive by the OpenTheory logical kernel. I assume you have already cloned my HOL Light fork with the OpenTheory proof logging, which is available from http://src.gilith.com/hol-light.html If you look at the top of opentheory/stdlib/stdlib.int, you can see the mapping that's used to translate the HOL Light names for the primitive symbols to the OpenTheory names. > FYI I fixed my Poly/ML problem, and now opentheory works like a charm :) Excellent news: please do let me know if you find any bugs in the tool. Cheers, Joe From rda at lemma-one.com Mon Oct 13 19:50:17 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 13 Oct 2014 20:50:17 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: Message-ID: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> Mario, Joe, On 13 Oct 2014, at 16:54, Joe Leslie-Hurd wrote: > Hi Mario, > >> The only >> conclusion I can draw is that dummy variables should never be generated in a >> formula where they would appear free, since there are no means to eliminate >> them. I'm surprised, then, that a and r aren't quantified in the outputs to >> defineTypeOp, because if they were you could use dummy variables rather than >> hardcoding the strings "a" and "r" into the implementation. > @Mario: The reason they aren?t quantified is because OpenTheory follows HOL Light in not wiring any dependency on the definitions of the logical connectives and quantifiers into the logical kernel. This means that they both have to represent the logical content of a the defining property of a new type without using universal quantification and implication, which they do using a theorem with assumptions and free variables. It would be really nice if there was a simple closed formula you could use instead, but no-one has come up with one. > I agree with your assessment that dummy free variables are a scourge, > and therefore in version 6 of the article standard I propose changing > the behaviour of defineTypeOp to take the names of the "a" and "r" > variables as additional arguments: @Joe: I have no strong objection to your proposal, but I don?t understand the reasons for it. My understanding of defineTypeOp in version 5 of the article standard was that the names of the variables in the theorem it produced were ?r? and ?a? (not dummies). So the onus is on an OpenTheory reader to make it so (by applying derived rules to the output of their ?native? type definition principle to give what the OpenTheory article spec requires). What you are now proposing makes it clearer that an OpenTheory reader has to have the capability to produce a defining property with any chosen variable names, but I don?t see what value it adds. It just gives a tiny extra burden to the implementor of an OpenTheory reader. > > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > > The nice thing is that literally any variable name will work, because > the two resulting theorems of defineTypeOp each have precisely one > free variable, so there's nothing to clash with. It's easy to recover > the legacy version 5 behaviour by simply passing in the names "a" and > "r". > > Does that satisfy your concerns? I believe that's the only instance in > the spec of dummy free variables, but please let me know if that's not > the case. @Joe: To reiterate, I don?t see why you think the spec required or suggested the introduction of dummy free variables. And I don?t see how it will help Mario - if his implementation of defineTypeOp produces a theorem with dummy variable names, then he will have to implement a derived rule to adjust those names to the ones specified in the article (as opposed to ?a? and ?r?, which is what you have to do with version 5 of the article standard). By the way, is the version 5 of the article standard available on-line. I have a paper copy somewhere, but it would be nice to have it available on-line for comparison with version 6. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Mon Oct 13 20:19:21 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Mon, 13 Oct 2014 13:19:21 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> Message-ID: Hi Rob, You're right, "a" and "r" are not dummy free variables, but rather hard-coded free variables in the rule. At present the only hard-coded names in the OpenTheory spec are the names of the primitive symbols, so this seemed a little inelegant to me. However, I accept your point that it complicates the spec (because readers have to implement the behaviour for both versions) and doesn't solve a real problem, so the proposed change may not be worth it. The easiest way of accessing version 5 of the article spec is to follow the link at the bottom of version 6, but here's the direct link for posterity: http://www.gilith.com/research/opentheory/article-5.html Cheers, Joe On Mon, Oct 13, 2014 at 12:50 PM, Rob Arthan wrote: > Mario, Joe, > > On 13 Oct 2014, at 16:54, Joe Leslie-Hurd wrote: > > Hi Mario, > > The only > conclusion I can draw is that dummy variables should never be generated in a > formula where they would appear free, since there are no means to eliminate > them. I'm surprised, then, that a and r aren't quantified in the outputs to > defineTypeOp, because if they were you could use dummy variables rather than > hardcoding the strings "a" and "r" into the implementation. > > > @Mario: > > The reason they aren't quantified is because OpenTheory follows HOL Light > in not wiring any dependency on the definitions of the logical connectives > and > quantifiers into the logical kernel. This means that they both have to > represent > the logical content of a the defining property of a new type without using > universal quantification and implication, which they do using a theorem with > assumptions and free variables. It would be really nice if there was a > simple > closed formula you could use instead, but no-one has come up with one. > > I agree with your assessment that dummy free variables are a scourge, > and therefore in version 6 of the article standard I propose changing > the behaviour of defineTypeOp to take the names of the "a" and "r" > variables as additional arguments: > > > @Joe: > > I have no strong objection to your proposal, but I don't understand the > reasons > for it. My understanding of defineTypeOp in version 5 of the article > standard > was that the names of the variables in the theorem it produced were > "r" and "a" (not dummies). So the onus is on an OpenTheory reader to make it > so > (by applying derived rules to the output of their "native" type definition > principle > to give what the OpenTheory article spec requires). > > What you are now proposing makes it clearer that an OpenTheory reader > has to have the capability to produce a defining property with any chosen > variable names, but I don't see what value it adds. It just gives a tiny > extra > burden to the implementor of an OpenTheory reader. > > > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > > The nice thing is that literally any variable name will work, because > the two resulting theorems of defineTypeOp each have precisely one > free variable, so there's nothing to clash with. It's easy to recover > the legacy version 5 behaviour by simply passing in the names "a" and > "r". > > Does that satisfy your concerns? I believe that's the only instance in > the spec of dummy free variables, but please let me know if that's not > the case. > > > @Joe: > > To reiterate, I don't see why you think the spec required or suggested > the introduction of dummy free variables. And I don't see how it will > help Mario - if his implementation of defineTypeOp produces a theorem > with dummy variable names, then he will have to implement a derived rule to > adjust those names to the ones specified in the article (as opposed to "a" > and > "r", which is what you have to do with version 5 of the article standard). > > By the way, is the version 5 of the article standard available on-line. > I have a paper copy somewhere, but it would be nice to have it available > on-line for comparison with version 6. > > Regards, > > Rob. > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From rda at lemma-one.com Mon Oct 13 20:52:06 2014 From: rda at lemma-one.com (Rob Arthan) Date: Mon, 13 Oct 2014 21:52:06 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> Message-ID: <46456745-BC17-42DA-8598-47A9FF4760DF@lemma-one.com> Joe, On 13 Oct 2014, at 21:19, Joe Leslie-Hurd wrote: > Hi Rob, > > You're right, "a" and "r" are not dummy free variables, but rather > hard-coded free variables in the rule. At present the only hard-coded > names in the OpenTheory spec are the names of the primitive symbols, > so this seemed a little inelegant to me. > > However, I accept your point that it complicates the spec (because > readers have to implement the behaviour for both versions) and doesn't > solve a real problem, so the proposed change may not be worth it. > For now, the only system we have to cope with that produces defining properties with free variables is HOL Light and it does this for type definitions only and it uses the fixed names ?a? and ?r? for the free variables. I appreciate, on reflection, that if it did generate fresh variable names, it would be a (not insuperable) challenge to implement an OpenTheory writer for it. On the other hand, why would anyone want a definitional principle that gave defining properties containing unpredictable free variable names? > The easiest way of accessing version 5 of the article spec is to > follow the link at the bottom of version 6, but here's the direct link > for posterity: > > http://www.gilith.com/research/opentheory/article-5.html Thanks. I did look at the end of version 6 and don?t know how I managed not to spot the link there. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Mon Oct 13 21:13:21 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Mon, 13 Oct 2014 17:13:21 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> Message-ID: Hi Rob, On Mon, Oct 13, 2014 at 3:50 PM, Rob Arthan wrote: > The reason they aren?t quantified is because OpenTheory follows HOL Light > in not wiring any dependency on the definitions of the logical connectives > and > quantifiers into the logical kernel. This means that they both have to > represent > the logical content of a the defining property of a new type without using > universal quantification and implication, which they do using a theorem > with > assumptions and free variables. It would be really nice if there was a > simple > closed formula you could use instead, but no-one has come up with one. > Well, there's no need to use the definition of ! : you could just write (\a. (abs (rep a)) = a) = (\a. a = a) (\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r) and since now the variables are bound, you are free to use whatever dummies you like. > To reiterate, I don?t see why you think the spec required or suggested > the introduction of dummy free variables. And I don?t see how it will > help Mario - if his implementation of defineTypeOp produces a theorem > with dummy variable names, then he will have to implement a derived rule to > adjust those names to the ones specified in the article (as opposed to ?a? > and > ?r?, which is what you have to do with version 5 of the article standard). > I have no strong feelings or difficulty implementing either standard; rather, as Joe suggested, I find it inelegant to hard-code anything into the spec that isn't necessary. The problem isn't that I am forced to invent a dummy variable, and have to convert it - it's that I have to name it *something*, and since there had been no previous examples of hard-coded names, it was my mistake to interpret the "a" and "r" as dummy names (which is another way to avoid hard-coded names, although as it turns out it's not a viable solution in this case). What I'm trying to do is offload as much responsibility for variable naming into the proof as possible, so that the spec doesn't have to pull names like "a" out of a hat (which may or may not conflict with another variable, or may just not be good variable names for the proof if one has a particular naming convention in mind). On Mon, Oct 13, 2014 at 4:52 PM, Rob Arthan wrote: > For now, the only system we have to cope with that produces defining > properties with free variables is HOL Light and it does this for type > definitions only and it uses the fixed names ?a? and ?r? for the free > variables. > I appreciate, on reflection, that if it did generate fresh variable names, > it > would be a (not insuperable) challenge to implement an OpenTheory writer > for it. > On the other hand, why would anyone want a definitional principle that > gave defining properties containing unpredictable free variable names? > For comparison purposes (and for a glimpse of where I'm coming from), Metamath does this for *every* axiom and theorem. For example, there is a theorem http://us.metamath.org/mpegif/rabid2.html, written in Metamath as: |- ( A = { x e. A | ph } <-> A. x e. A ph ) and which could be translated into HOL as |- ((a = (\x. (a x) /\ (P x))) = (!x. (a x) ==> (P x))) When applied as a step in another theorem, the stack machine accepts the label "rabid2" as the command, and treats it as if it were a primitive inference rule which pops "var v", "class B", "wff ps" off the stack (equivalents to "var" and "term" stack entries - here v is an arbitrary variable and B stands for any valid class expression, and ps is any valid wff), and pushes the theorem |- ( B = { y e. B | ps } <-> A. y e. B ps ) onto the stack. The original (non-substituted) formula, which had previously been exported, never appears on the stack at any point. Thus Metamath is essentially "subst"-ing every single formula that appears on the stack, which on the one hand makes it very powerful, but it does not actually contain a "subst" command, so a formula already on the stack cannot be further substituted unless you get a fresh copy from whatever formulas you derived it from or break off a new lemma. Metamath has nothing hardcoded at all, not even "primitive rules of inference", just this "subst"-like behavior, and axioms which are specified during execution. That's part of the reason why I internally reject having to make arbitrary decisions regarding variable naming which should rightly be done by the proof writer and their own naming sense. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Wed Oct 15 13:13:57 2014 From: rda at lemma-one.com (Rob Arthan) Date: Wed, 15 Oct 2014 14:13:57 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> Message-ID: <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> Mario, On 13 Oct 2014, at 22:13, Mario Carneiro wrote: > Hi Rob, > > On Mon, Oct 13, 2014 at 3:50 PM, Rob Arthan wrote: > The reason they aren?t quantified is because OpenTheory follows HOL Light > in not wiring any dependency on the definitions of the logical connectives and > quantifiers into the logical kernel. This means that they both have to represent > the logical content of a the defining property of a new type without using > universal quantification and implication, which they do using a theorem with > assumptions and free variables. It would be really nice if there was a simple > closed formula you could use instead, but no-one has come up with one. > > Well, there's no need to use the definition of ! : you could just write > > (\a. (abs (rep a)) = a) = (\a. a = a) > (\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r) > > and since now the variables are bound, you are free to use whatever dummies you like. But that?s just expanding the definition of the connectives and it?s not very pretty. (Strictly speaking, I don?t know whether it is expanding the definition of the connectives or not, since you haven?t told me what the type of the second variable called r is, and for technical reasons it is boolean in the definition of T.) > > To reiterate, I don?t see why you think the spec required or suggested > the introduction of dummy free variables. And I don?t see how it will > help Mario - if his implementation of defineTypeOp produces a theorem > with dummy variable names, then he will have to implement a derived rule to > adjust those names to the ones specified in the article (as opposed to ?a? and > ?r?, which is what you have to do with version 5 of the article standard). > > I have no strong feelings or difficulty implementing either standard; rather, as Joe suggested, I find it inelegant to hard-code anything into the spec that isn't necessary. The problem isn't that I am forced to invent a dummy variable, and have to convert it - it's that I have to name it *something*, and since there had been no previous examples of hard-coded names, it was my mistake to interpret the "a" and "r" as dummy names (which is another way to avoid hard-coded names, although as it turns out it's not a viable solution in this case). What I'm trying to do is offload as much responsibility for variable naming into the proof as possible, so that the spec doesn't have to pull names like "a" out of a hat (which may or may not conflict with another variable, or may just not be good variable names for the proof if one has a particular naming convention in mind). > > > > On Mon, Oct 13, 2014 at 4:52 PM, Rob Arthan wrote: > For now, the only system we have to cope with that produces defining > properties with free variables is HOL Light and it does this for type > definitions only and it uses the fixed names ?a? and ?r? for the free variables. > I appreciate, on reflection, that if it did generate fresh variable names, it > would be a (not insuperable) challenge to implement an OpenTheory writer for it. > On the other hand, why would anyone want a definitional principle that > gave defining properties containing unpredictable free variable names? > I misunderstood what was going on. I thought you were introducing dummy names you had an existing implementation of something like defineConst that was forcing you to use invented variable names. I didn?t realise you had a choice. > For comparison purposes (and for a glimpse of where I'm coming from), Metamath does this for *every* axiom and theorem. For example, there is a theorem http://us.metamath.org/mpegif/rabid2.html, written in Metamath as: > > |- ( A = { x e. A | ph } <-> A. x e. A ph ) > > and which could be translated into HOL as > > |- ((a = (\x. (a x) /\ (P x))) = (!x. (a x) ==> (P x))) > > When applied as a step in another theorem, the stack machine accepts the label "rabid2" as the command, and treats it as if it were a primitive inference rule which pops "var v", "class B", "wff ps" off the stack (equivalents to "var" and "term" stack entries - here v is an arbitrary variable and B stands for any valid class expression, and ps is any valid wff), and pushes the theorem > > |- ( B = { y e. B | ps } <-> A. y e. B ps ) > > onto the stack. The original (non-substituted) formula, which had previously been exported, never appears on the stack at any point. Thus Metamath is essentially "subst"-ing every single formula that appears on the stack, which on the one hand makes it very powerful, but it does not actually contain a "subst" command, so a formula already on the stack cannot be further substituted unless you get a fresh copy from whatever formulas you derived it from or break off a new lemma. > > Metamath has nothing hardcoded at all, not even "primitive rules of inference", just this "subst"-like behavior, and axioms which are specified during execution. That's part of the reason why I internally reject having to make arbitrary decisions regarding variable naming which should rightly be done by the proof writer and their own naming sense. Unfortunately that is just not how it is in HOL Light. The way the equivalent of defineTypeOp is implemented in HOL4 and ProofPower gives a defining property with no free variables. But the HOL4 and ProofPower kernels require that the logical connectives and one or two other constants are pre-defined. The HOL Light and OpenTheory kernels don?t make this requirement, but this causes them to produce defining properties for type with free variables. I am rather inclined to agree with you that the names of those free variables should be the user?s choice. But that is not how HOL Light is at the moment. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 01:30:18 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Wed, 15 Oct 2014 21:30:18 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> Message-ID: Rob, > Well, there's no need to use the definition of ! : you could just write > > (\a. (abs (rep a)) = a) = (\a. a = a) > (\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r) > > and since now the variables are bound, you are free to use whatever > dummies you like. > > > But that?s just expanding the definition of the connectives and it?s not > very pretty. > (Strictly speaking, I don?t know whether it is expanding the definition of > the > connectives or not, since you haven?t told me what the type of the second > variable called r is, and for technical reasons it is boolean in the > definition > of T.) > Actually, it's not just expanding the definition of the connectives, which would give (\a:A. (abs (rep a)) = a) = (\a. \p:bool. p = \p. p ) (\r:B. (P r) = ((rep (abs r)) = r)) = (\r. \p:bool. p = \p. p) The variables a and r there have the same type in each abstraction, because the type of the abstraction in the first case is (A->bool) and carries the type over to the other abstraction. I realize that it's not that elegant, but if you want to eliminate free variables and still have the same result, that's the simplest way to do it. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Thu Oct 16 07:18:30 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 16 Oct 2014 08:18:30 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> Message-ID: <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Mario, On 16 Oct 2014, at 02:30, Mario Carneiro wrote: > Rob, >> Well, there's no need to use the definition of ! : you could just write >> >> (\a. (abs (rep a)) = a) = (\a. a = a) >> (\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r) >> >> and since now the variables are bound, you are free to use whatever dummies you like. > > But that?s just expanding the definition of the connectives and it?s not very pretty. > (Strictly speaking, I don?t know whether it is expanding the definition of the > connectives or not, since you haven?t told me what the type of the second > variable called r is, and for technical reasons it is boolean in the definition > of T.) > > Actually, it's not just expanding the definition of the connectives, which would give > > (\a:A. (abs (rep a)) = a) = (\a. \p:bool. p = \p. p ) > (\r:B. (P r) = ((rep (abs r)) = r)) = (\r. \p:bool. p = \p. p) > > The variables a and r there have the same type in each abstraction, because the type of the abstraction in the first case is (A->bool) and carries the type over to the other abstraction. I realize that it's not that elegant, but if you want to eliminate free variables and still have the same result, that's the simplest way to do it. Can you prove that? E.g., if the measure of simplicity is the number of symbols? Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 07:36:46 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 03:36:46 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: On Thu, Oct 16, 2014 at 3:18 AM, Rob Arthan wrote: > Mario, > > On 16 Oct 2014, at 02:30, Mario Carneiro wrote: > > Rob, > >> Well, there's no need to use the definition of ! : you could just write >> >> (\a. (abs (rep a)) = a) = (\a. a = a) >> (\r. (P r) = ((rep (abs r)) = r)) = (\r. r = r) >> >> and since now the variables are bound, you are free to use whatever >> dummies you like. >> >> >> But that?s just expanding the definition of the connectives and it?s not >> very pretty. >> (Strictly speaking, I don?t know whether it is expanding the definition >> of the >> connectives or not, since you haven?t told me what the type of the second >> variable called r is, and for technical reasons it is boolean in the >> definition >> of T.) >> > > Actually, it's not just expanding the definition of the connectives, which > would give > > (\a:A. (abs (rep a)) = a) = (\a. \p:bool. p = \p. p ) > (\r:B. (P r) = ((rep (abs r)) = r)) = (\r. \p:bool. p = \p. p) > > The variables a and r there have the same type in each abstraction, > because the type of the abstraction in the first case is (A->bool) and > carries the type over to the other abstraction. I realize that it's not > that elegant, but if you want to eliminate free variables and still have > the same result, that's the simplest way to do it. > > > Can you prove that? E.g., if the measure of simplicity is the number of > symbols? > > Regards, > > Rob. > Actually, that was a lie, because I just thought of an even simpler way to quantify the statement "(abs (rep a)) = a", and that's \a. (abs (rep a)) = \a. a and similarly for the other: P = \r. ((rep (abs r)) = r Assuming that (abs (rep a)) = a is the shortest way to express the original claim, I am confident that this is the symbol-minimal quantified version of the same formula. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Thu Oct 16 07:43:40 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Thu, 16 Oct 2014 08:43:40 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro wrote: > Assuming that (abs (rep a)) = a is the shortest way to express the > original claim, I am confident that this is the symbol-minimal quantified > version of the same formula. > What if we relax that assumption? -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 07:57:52 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 03:57:52 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: On Thu, Oct 16, 2014 at 3:43 AM, Ramana Kumar wrote: > On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro wrote: > >> Assuming that (abs (rep a)) = a is the shortest way to express the >> original claim, I am confident that this is the symbol-minimal quantified >> version of the same formula. >> > > What if we relax that assumption? > A really clever way of writing it would be (abs o. rep) = id , where o. is composition, but I don't think there is a way to write that using primitives any simpler than \a. (abs (rep a)) = \a. a. You already know that it needs a dummy variable (because things like (abs rep) are not well-typed, and you have no other objects using type A), needs to have abs and rep, and needs to be quantified over the dummy variable (once on each side of the equality so the types match), which gives \a. (abs (rep a)) = \a. ? where the a on the left may possibly be somewhere else. There really aren't too many options that are even shorter than \a. (abs (rep a)) = \a. a, so I would say that it's probably as good as it gets. For the other one, there are no spare symbols in P = \r. ((rep (abs r)) = r, so again I think that's minimal. A rigorous proof would need an enumeration of all smaller formulas, but it's hard to see anything well-typed that is any smaller than this and still uses all the essential elements. -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 08:04:45 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 04:04:45 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: If you allow combining the two equations into one, there is also the option P = \r. (\a. ((rep a) = r) = \a. ((abs r) = a)) On Thu, Oct 16, 2014 at 3:57 AM, Mario Carneiro wrote: > > > On Thu, Oct 16, 2014 at 3:43 AM, Ramana Kumar > wrote: > >> On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro >> wrote: >> >>> Assuming that (abs (rep a)) = a is the shortest way to express the >>> original claim, I am confident that this is the symbol-minimal quantified >>> version of the same formula. >>> >> >> What if we relax that assumption? >> > > A really clever way of writing it would be (abs o. rep) = id , where o. is > composition, but I don't think there is a way to write that using > primitives any simpler than \a. (abs (rep a)) = \a. a. You already know > that it needs a dummy variable (because things like (abs rep) are not > well-typed, and you have no other objects using type A), needs to have abs > and rep, and needs to be quantified over the dummy variable (once on each > side of the equality so the types match), which gives \a. (abs (rep a)) = > \a. ? where the a on the left may possibly be somewhere else. There really > aren't too many options that are even shorter than \a. (abs (rep a)) = > \a. a, so I would say that it's probably as good as it gets. For the other > one, there are no spare symbols in P = \r. ((rep (abs r)) = r, so again I > think that's minimal. A rigorous proof would need an enumeration of all > smaller formulas, but it's hard to see anything well-typed that is any > smaller than this and still uses all the essential elements. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 08:17:49 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 04:17:49 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: ...which can also be written P = \r. (\a. ((rep a) = r) = (= (abs r))) (although using curried = that way is a bit strange) On Thu, Oct 16, 2014 at 4:04 AM, Mario Carneiro wrote: > If you allow combining the two equations into one, there is also the option > > P = \r. (\a. ((rep a) = r) = \a. ((abs r) = a)) > > On Thu, Oct 16, 2014 at 3:57 AM, Mario Carneiro wrote: > >> >> >> On Thu, Oct 16, 2014 at 3:43 AM, Ramana Kumar >> wrote: >> >>> On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro >>> wrote: >>> >>>> Assuming that (abs (rep a)) = a is the shortest way to express the >>>> original claim, I am confident that this is the symbol-minimal quantified >>>> version of the same formula. >>>> >>> >>> What if we relax that assumption? >>> >> >> A really clever way of writing it would be (abs o. rep) = id , where o. >> is composition, but I don't think there is a way to write that using >> primitives any simpler than \a. (abs (rep a)) = \a. a. You already know >> that it needs a dummy variable (because things like (abs rep) are not >> well-typed, and you have no other objects using type A), needs to have abs >> and rep, and needs to be quantified over the dummy variable (once on each >> side of the equality so the types match), which gives \a. (abs (rep a)) = >> \a. ? where the a on the left may possibly be somewhere else. There really >> aren't too many options that are even shorter than \a. (abs (rep a)) = >> \a. a, so I would say that it's probably as good as it gets. For the other >> one, there are no spare symbols in P = \r. ((rep (abs r)) = r, so again >> I think that's minimal. A rigorous proof would need an enumeration of all >> smaller formulas, but it's hard to see anything well-typed that is any >> smaller than this and still uses all the essential elements. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ramana at member.fsf.org Thu Oct 16 08:19:10 2014 From: ramana at member.fsf.org (Ramana Kumar) Date: Thu, 16 Oct 2014 09:19:10 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: I think that is weaker than the 2 original axioms. We need to know abs is a left-inverse of rep regardless of P. On Thu, Oct 16, 2014 at 9:17 AM, Mario Carneiro wrote: > ...which can also be written > > P = \r. (\a. ((rep a) = r) = (= (abs r))) > > (although using curried = that way is a bit strange) > > On Thu, Oct 16, 2014 at 4:04 AM, Mario Carneiro wrote: > >> If you allow combining the two equations into one, there is also the >> option >> >> P = \r. (\a. ((rep a) = r) = \a. ((abs r) = a)) >> >> On Thu, Oct 16, 2014 at 3:57 AM, Mario Carneiro >> wrote: >> >>> >>> >>> On Thu, Oct 16, 2014 at 3:43 AM, Ramana Kumar >>> wrote: >>> >>>> On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro >>>> wrote: >>>> >>>>> Assuming that (abs (rep a)) = a is the shortest way to express the >>>>> original claim, I am confident that this is the symbol-minimal quantified >>>>> version of the same formula. >>>>> >>>> >>>> What if we relax that assumption? >>>> >>> >>> A really clever way of writing it would be (abs o. rep) = id , where o. >>> is composition, but I don't think there is a way to write that using >>> primitives any simpler than \a. (abs (rep a)) = \a. a. You already know >>> that it needs a dummy variable (because things like (abs rep) are not >>> well-typed, and you have no other objects using type A), needs to have abs >>> and rep, and needs to be quantified over the dummy variable (once on each >>> side of the equality so the types match), which gives \a. (abs (rep a)) = >>> \a. ? where the a on the left may possibly be somewhere else. There really >>> aren't too many options that are even shorter than \a. (abs (rep a)) = >>> \a. a, so I would say that it's probably as good as it gets. For the other >>> one, there are no spare symbols in P = \r. ((rep (abs r)) = r, so again >>> I think that's minimal. A rigorous proof would need an enumeration of all >>> smaller formulas, but it's hard to see anything well-typed that is any >>> smaller than this and still uses all the essential elements. >>> >> >> > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 08:48:20 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 04:48:20 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: On Thu, Oct 16, 2014 at 4:19 AM, Ramana Kumar wrote: > I think that is weaker than the 2 original axioms. We need to know abs is > a left-inverse of rep regardless of P. > Ah, yes I think you're right - it seems the best you can derive from that is (P (rep a)) = ((abs (rep a)) = a). Never mind then. Mario -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Thu Oct 16 09:21:18 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 16 Oct 2014 10:21:18 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: <712BF316-7F85-4C22-B47E-2B49E6660DA4@lemma-one.com> Mario, On 16 Oct 2014, at 08:57, Mario Carneiro wrote: > > > On Thu, Oct 16, 2014 at 3:43 AM, Ramana Kumar wrote: > On Thu, Oct 16, 2014 at 8:36 AM, Mario Carneiro wrote: > Assuming that (abs (rep a)) = a is the shortest way to express the original claim, I am confident that this is the symbol-minimal quantified version of the same formula. > > What if we relax that assumption? > > A really clever way of writing it would be (abs o. rep) = id , where o. is composition, but I don't think there is a way to write that using primitives any simpler than \a. (abs (rep a)) = \a. a. You already know that it needs a dummy variable (because things like (abs rep) are not well-typed, and you have no other objects using type A), needs to have abs and rep, and needs to be quantified over the dummy variable (once on each side of the equality so the types match), which gives \a. (abs (rep a)) = \a. ? where the a on the left may possibly be somewhere else. There really aren't too many options that are even shorter than \a. (abs (rep a)) = \a. a, so I would say that it's probably as good as it gets. For the other one, there are no spare symbols in P = \r. ((rep (abs r)) = r, so again I think that's minimal. A rigorous proof would need an enumeration of all smaller formulas, but it's hard to see anything well-typed that is any smaller than this and still uses all the essential elements. Well done! I wasn?t really expecting a rigorous proof. The characterisations \a. (abs (rep a)) = \a.a P = \r. ((rep (abs r)) = r that you have arrived at would provide a nice alternative to what HOL Light currently offers. It would be really nice if there was a simple replacement within the typed lambda-calculus for the HOL4 characterisation of a new type. Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rda at lemma-one.com Thu Oct 16 16:22:42 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 16 Oct 2014 17:22:42 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> Message-ID: <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> Mario, On 16 Oct 2014, at 08:36, Mario Carneiro wrote: > > \a. (abs (rep a)) = \a. a > > and similarly for the other: > > P = \r. ((rep (abs r)) = r > In fact, you win today?s star prize, because the above characterisations give a workable way of formulating using only the typed lambda calculus the type specification principle that is discussed in the HOL4 documentation, but has never actually been implemented (despite having some really nice properties). As described in the HOL4 logic manual, the type specification principle would not be acceptable in the HOL Light or OpenTheory kernels because it depends on various non-primitive constants. The problem is to express using only the typed lambda-calculus something equiprovable with the following sequent, (*) say; Gamma |- (?f. TypeDefn P f) => Q where P and Q are closed terms satisfying certain conditions. From this (and another theorem that is easy to express without the logical connectives), you get a new type operator (alpha1, ? alphaN) op whose defining property is q[alpha1, ? alphaN) op/alpha]. This generalises new_type_definition, which is the special case when Gamma is empty and Q is ?f.TypeDefn P f. Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, where R P abs rep asserts that abs is left-inverse to rep and that rep is left-inverse to abs precisely where P holds (i.e., the properties that new_type_definition gives you of the abstraction and representation functions that HOL Light insists on defining for you). So (*) is equivalent to (**): Gamma |- (?abs.?rep. R P abs rep) => Q By first-order logic, (**) is equiprovable with: Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q I had been fiddling around with various not very nice approximations to the above. With your improvements you get something that is relatively easy to understand and is simple enough to propose for serious consideration as a more general replacement for new_type_definition. (Note that it also satisfies you desiderata for naming things: the names of rep and abs above are whatever the user chooses.) Regards, Rob. -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Thu Oct 16 18:06:39 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 16 Oct 2014 11:06:39 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> Message-ID: Hi Rob, That is a very nice idea for a new_type_specification that is compatible with the HOL Light and OpenTheory kernels: I like that it doesn't define new constants with the new type operator, which always seemed a bit inelegant to me. In the immediate term, I wonder if we can now agree that the benefits of Mario's new formulation of defineTypeOp are significant enough to change the OpenTheory article spec as follows? http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand I very much like the removal of hard-coded free variables (as opposed to providing additional arguments to specify their name), and the formulation simplifies the explanation of a future new_type_specification article command. As before, the cost is that readers have to implement both the old and new behaviors. Cheers, Joe On Thu, Oct 16, 2014 at 9:22 AM, Rob Arthan wrote: > Mario, > > On 16 Oct 2014, at 08:36, Mario Carneiro wrote: > > > \a. (abs (rep a)) = \a. a > > and similarly for the other: > > P = \r. ((rep (abs r)) = r > > > In fact, you win today's star prize, because the above characterisations > give a workable way of formulating using only the typed lambda calculus > the type specification principle that is discussed in the HOL4 > documentation, > but has never actually been implemented (despite having some really nice > properties). > > As described in the HOL4 logic manual, the type specification principle > would not be acceptable in the HOL Light or OpenTheory kernels because > it depends on various non-primitive constants. The problem is to > express using only the typed lambda-calculus something equiprovable with > the following sequent, (*) say; > > Gamma |- (?f. TypeDefn P f) => Q > > where P and Q are closed terms satisfying certain conditions. > From this (and another theorem that is easy to express without > the logical connectives), you get a new type operator (alpha1, ... alphaN) op > whose defining property is q[alpha1, ... alphaN) op/alpha]. > This generalises new_type_definition, which is the special case when > Gamma is empty and Q is ?f.TypeDefn P f. > > Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, > where R P abs rep asserts that abs is left-inverse to rep and that > rep is left-inverse to abs precisely where P holds (i.e., the properties > that new_type_definition gives you of the abstraction and > representation functions that HOL Light insists on defining for you). > So (*) is equivalent to (**): > > Gamma |- (?abs.?rep. R P abs rep) => Q > > By first-order logic, (**) is equiprovable with: > > Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q > > I had been fiddling around with various not very nice > approximations to the above. With your improvements you get > something that is relatively easy to understand and is > simple enough to propose for serious consideration > as a more general replacement for new_type_definition. > (Note that it also satisfies you desiderata for naming things: > the names of rep and abs above are whatever the user chooses.) > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From rda at lemma-one.com Thu Oct 16 20:43:49 2014 From: rda at lemma-one.com (Rob Arthan) Date: Thu, 16 Oct 2014 21:43:49 +0100 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> Message-ID: <060F18E8-BF69-4ECA-AE83-F9EB714E2ED6@lemma-one.com> Joe, I am certainly happy with the new way of formulating defineTypeOp. Regards, Rob. On 16 Oct 2014, at 19:06, Joe Leslie-Hurd wrote: > Hi Rob, > > That is a very nice idea for a new_type_specification that is > compatible with the HOL Light and OpenTheory kernels: I like that it > doesn't define new constants with the new type operator, which always > seemed a bit inelegant to me. > > In the immediate term, I wonder if we can now agree that the benefits > of Mario's new formulation of defineTypeOp are significant enough to > change the OpenTheory article spec as follows? > > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > > I very much like the removal of hard-coded free variables (as opposed > to providing additional arguments to specify their name), and the > formulation simplifies the explanation of a future > new_type_specification article command. As before, the cost is that > readers have to implement both the old and new behaviors. > > Cheers, > > Joe > > On Thu, Oct 16, 2014 at 9:22 AM, Rob Arthan wrote: >> Mario, >> >> On 16 Oct 2014, at 08:36, Mario Carneiro wrote: >> >> >> \a. (abs (rep a)) = \a. a >> >> and similarly for the other: >> >> P = \r. ((rep (abs r)) = r >> >> >> In fact, you win today's star prize, because the above characterisations >> give a workable way of formulating using only the typed lambda calculus >> the type specification principle that is discussed in the HOL4 >> documentation, >> but has never actually been implemented (despite having some really nice >> properties). >> >> As described in the HOL4 logic manual, the type specification principle >> would not be acceptable in the HOL Light or OpenTheory kernels because >> it depends on various non-primitive constants. The problem is to >> express using only the typed lambda-calculus something equiprovable with >> the following sequent, (*) say; >> >> Gamma |- (?f. TypeDefn P f) => Q >> >> where P and Q are closed terms satisfying certain conditions. >> From this (and another theorem that is easy to express without >> the logical connectives), you get a new type operator (alpha1, ... alphaN) op >> whose defining property is q[alpha1, ... alphaN) op/alpha]. >> This generalises new_type_definition, which is the special case when >> Gamma is empty and Q is ?f.TypeDefn P f. >> >> Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, >> where R P abs rep asserts that abs is left-inverse to rep and that >> rep is left-inverse to abs precisely where P holds (i.e., the properties >> that new_type_definition gives you of the abstraction and >> representation functions that HOL Light insists on defining for you). >> So (*) is equivalent to (**): >> >> Gamma |- (?abs.?rep. R P abs rep) => Q >> >> By first-order logic, (**) is equiprovable with: >> >> Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q >> >> I had been fiddling around with various not very nice >> approximations to the above. With your improvements you get >> something that is relatively easy to understand and is >> simple enough to propose for serious consideration >> as a more general replacement for new_type_definition. >> (Note that it also satisfies you desiderata for naming things: >> the names of rep and abs above are whatever the user chooses.) >> >> Regards, >> >> Rob. >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 21:47:09 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 17:47:09 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: <060F18E8-BF69-4ECA-AE83-F9EB714E2ED6@lemma-one.com> References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> <060F18E8-BF69-4ECA-AE83-F9EB714E2ED6@lemma-one.com> Message-ID: By the way, would it be possible to highlight breaking changes differently from non-breaking changes in v6? For example, a v5 reader will still work if it implements hdTl, because any file using that will not be valid under the spec so that code would just be dormant assuming the article file is valid. Are there any other commands whose behavior is different other than defineTypeOp? On Thu, Oct 16, 2014 at 4:43 PM, Rob Arthan wrote: > Joe, > > I am certainly happy with the new way of formulating defineTypeOp. > > Regards, > > Rob. > > On 16 Oct 2014, at 19:06, Joe Leslie-Hurd wrote: > > Hi Rob, > > That is a very nice idea for a new_type_specification that is > compatible with the HOL Light and OpenTheory kernels: I like that it > doesn't define new constants with the new type operator, which always > seemed a bit inelegant to me. > > In the immediate term, I wonder if we can now agree that the benefits > of Mario's new formulation of defineTypeOp are significant enough to > change the OpenTheory article spec as follows? > > http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand > > I very much like the removal of hard-coded free variables (as opposed > to providing additional arguments to specify their name), and the > formulation simplifies the explanation of a future > new_type_specification article command. As before, the cost is that > readers have to implement both the old and new behaviors. > > Cheers, > > Joe > > On Thu, Oct 16, 2014 at 9:22 AM, Rob Arthan wrote: > > Mario, > > On 16 Oct 2014, at 08:36, Mario Carneiro wrote: > > > \a. (abs (rep a)) = \a. a > > and similarly for the other: > > P = \r. ((rep (abs r)) = r > > > In fact, you win today's star prize, because the above characterisations > give a workable way of formulating using only the typed lambda calculus > the type specification principle that is discussed in the HOL4 > documentation, > but has never actually been implemented (despite having some really nice > properties). > > As described in the HOL4 logic manual, the type specification principle > would not be acceptable in the HOL Light or OpenTheory kernels because > it depends on various non-primitive constants. The problem is to > express using only the typed lambda-calculus something equiprovable with > the following sequent, (*) say; > > Gamma |- (?f. TypeDefn P f) => Q > > where P and Q are closed terms satisfying certain conditions. > From this (and another theorem that is easy to express without > the logical connectives), you get a new type operator (alpha1, ... alphaN) > op > whose defining property is q[alpha1, ... alphaN) op/alpha]. > This generalises new_type_definition, which is the special case when > Gamma is empty and Q is ?f.TypeDefn P f. > > Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, > where R P abs rep asserts that abs is left-inverse to rep and that > rep is left-inverse to abs precisely where P holds (i.e., the properties > that new_type_definition gives you of the abstraction and > representation functions that HOL Light insists on defining for you). > So (*) is equivalent to (**): > > Gamma |- (?abs.?rep. R P abs rep) => Q > > By first-order logic, (**) is equiprovable with: > > Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q > > I had been fiddling around with various not very nice > approximations to the above. With your improvements you get > something that is relatively easy to understand and is > simple enough to propose for serious consideration > as a more general replacement for new_type_definition. > (Note that it also satisfies you desiderata for naming things: > the names of rep and abs above are whatever the user chooses.) > > Regards, > > Rob. > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From di.gama at gmail.com Thu Oct 16 21:50:14 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Thu, 16 Oct 2014 17:50:14 -0400 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> <060F18E8-BF69-4ECA-AE83-F9EB714E2ED6@lemma-one.com> Message-ID: Alternatively, if the command was named something else, like defineTypeOp6, then readers could be backwards-compatible without you having to select the article format (which I don't think is written anywhere in the file, so you'd have to supply this externally or else try to process and wait for an error before switching standards). On Thu, Oct 16, 2014 at 5:47 PM, Mario Carneiro wrote: > By the way, would it be possible to highlight breaking changes differently > from non-breaking changes in v6? For example, a v5 reader will still work > if it implements hdTl, because any file using that will not be valid under > the spec so that code would just be dormant assuming the article file is > valid. Are there any other commands whose behavior is different other than > defineTypeOp? > > On Thu, Oct 16, 2014 at 4:43 PM, Rob Arthan wrote: > >> Joe, >> >> I am certainly happy with the new way of formulating defineTypeOp. >> >> Regards, >> >> Rob. >> >> On 16 Oct 2014, at 19:06, Joe Leslie-Hurd wrote: >> >> Hi Rob, >> >> That is a very nice idea for a new_type_specification that is >> compatible with the HOL Light and OpenTheory kernels: I like that it >> doesn't define new constants with the new type operator, which always >> seemed a bit inelegant to me. >> >> In the immediate term, I wonder if we can now agree that the benefits >> of Mario's new formulation of defineTypeOp are significant enough to >> change the OpenTheory article spec as follows? >> >> http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand >> >> I very much like the removal of hard-coded free variables (as opposed >> to providing additional arguments to specify their name), and the >> formulation simplifies the explanation of a future >> new_type_specification article command. As before, the cost is that >> readers have to implement both the old and new behaviors. >> >> Cheers, >> >> Joe >> >> On Thu, Oct 16, 2014 at 9:22 AM, Rob Arthan wrote: >> >> Mario, >> >> On 16 Oct 2014, at 08:36, Mario Carneiro wrote: >> >> >> \a. (abs (rep a)) = \a. a >> >> and similarly for the other: >> >> P = \r. ((rep (abs r)) = r >> >> >> In fact, you win today's star prize, because the above characterisations >> give a workable way of formulating using only the typed lambda calculus >> the type specification principle that is discussed in the HOL4 >> documentation, >> but has never actually been implemented (despite having some really nice >> properties). >> >> As described in the HOL4 logic manual, the type specification principle >> would not be acceptable in the HOL Light or OpenTheory kernels because >> it depends on various non-primitive constants. The problem is to >> express using only the typed lambda-calculus something equiprovable with >> the following sequent, (*) say; >> >> Gamma |- (?f. TypeDefn P f) => Q >> >> where P and Q are closed terms satisfying certain conditions. >> From this (and another theorem that is easy to express without >> the logical connectives), you get a new type operator (alpha1, ... >> alphaN) op >> whose defining property is q[alpha1, ... alphaN) op/alpha]. >> This generalises new_type_definition, which is the special case when >> Gamma is empty and Q is ?f.TypeDefn P f. >> >> Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, >> where R P abs rep asserts that abs is left-inverse to rep and that >> rep is left-inverse to abs precisely where P holds (i.e., the properties >> that new_type_definition gives you of the abstraction and >> representation functions that HOL Light insists on defining for you). >> So (*) is equivalent to (**): >> >> Gamma |- (?abs.?rep. R P abs rep) => Q >> >> By first-order logic, (**) is equiprovable with: >> >> Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q >> >> I had been fiddling around with various not very nice >> approximations to the above. With your improvements you get >> something that is relatively easy to understand and is >> simple enough to propose for serious consideration >> as a more general replacement for new_type_definition. >> (Note that it also satisfies you desiderata for naming things: >> the names of rep and abs above are whatever the user chooses.) >> >> Regards, >> >> Rob. >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> >> >> _______________________________________________ >> opentheory-users mailing list >> opentheory-users at gilith.com >> http://www.gilith.com/mailman/listinfo/opentheory-users >> >> >> >> _______________________________________________ >> 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 Oct 16 22:47:04 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Thu, 16 Oct 2014 15:47:04 -0700 Subject: [opentheory-users] Troubleshooting an article reader In-Reply-To: References: <0F0FA4E0-01E4-440B-AEA8-615FDF41B254@lemma-one.com> <760F4852-1C94-4522-9B15-DDB7F9DF2225@lemma-one.com> <994CB855-AE80-43D8-AE3C-E610DF0059A9@lemma-one.com> <1F8DF899-F6F8-40AA-AA6E-E3A7D4906A10@lemma-one.com> <060F18E8-BF69-4ECA-AE83-F9EB714E2ED6@lemma-one.com> Message-ID: Hi Mario, Thanks for the suggestions: I've coloured the commands differently according to whether they are new or changed: http://www.gilith.com/research/opentheory/article.html#commands Thus far defineTypeOp is the only changed command. Instead of appending the version number to command names, the version command http://www.gilith.com/research/opentheory/article.html#versionCommand is used to globally specify the version of all commands in the file (and allows for more significant future changes to the article format than simply adding commands). Cheers, Joe On Thu, Oct 16, 2014 at 2:50 PM, Mario Carneiro wrote: > Alternatively, if the command was named something else, like defineTypeOp6, > then readers could be backwards-compatible without you having to select the > article format (which I don't think is written anywhere in the file, so > you'd have to supply this externally or else try to process and wait for an > error before switching standards). > > On Thu, Oct 16, 2014 at 5:47 PM, Mario Carneiro wrote: >> >> By the way, would it be possible to highlight breaking changes differently >> from non-breaking changes in v6? For example, a v5 reader will still work if >> it implements hdTl, because any file using that will not be valid under the >> spec so that code would just be dormant assuming the article file is valid. >> Are there any other commands whose behavior is different other than >> defineTypeOp? >> >> On Thu, Oct 16, 2014 at 4:43 PM, Rob Arthan wrote: >>> >>> Joe, >>> >>> I am certainly happy with the new way of formulating defineTypeOp. >>> >>> Regards, >>> >>> Rob. >>> >>> On 16 Oct 2014, at 19:06, Joe Leslie-Hurd wrote: >>> >>> Hi Rob, >>> >>> That is a very nice idea for a new_type_specification that is >>> compatible with the HOL Light and OpenTheory kernels: I like that it >>> doesn't define new constants with the new type operator, which always >>> seemed a bit inelegant to me. >>> >>> In the immediate term, I wonder if we can now agree that the benefits >>> of Mario's new formulation of defineTypeOp are significant enough to >>> change the OpenTheory article spec as follows? >>> >>> >>> http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand >>> >>> I very much like the removal of hard-coded free variables (as opposed >>> to providing additional arguments to specify their name), and the >>> formulation simplifies the explanation of a future >>> new_type_specification article command. As before, the cost is that >>> readers have to implement both the old and new behaviors. >>> >>> Cheers, >>> >>> Joe >>> >>> On Thu, Oct 16, 2014 at 9:22 AM, Rob Arthan wrote: >>> >>> Mario, >>> >>> On 16 Oct 2014, at 08:36, Mario Carneiro wrote: >>> >>> >>> \a. (abs (rep a)) = \a. a >>> >>> and similarly for the other: >>> >>> P = \r. ((rep (abs r)) = r >>> >>> >>> In fact, you win today's star prize, because the above characterisations >>> give a workable way of formulating using only the typed lambda calculus >>> the type specification principle that is discussed in the HOL4 >>> documentation, >>> but has never actually been implemented (despite having some really nice >>> properties). >>> >>> As described in the HOL4 logic manual, the type specification principle >>> would not be acceptable in the HOL Light or OpenTheory kernels because >>> it depends on various non-primitive constants. The problem is to >>> express using only the typed lambda-calculus something equiprovable with >>> the following sequent, (*) say; >>> >>> Gamma |- (?f. TypeDefn P f) => Q >>> >>> where P and Q are closed terms satisfying certain conditions. >>> From this (and another theorem that is easy to express without >>> the logical connectives), you get a new type operator (alpha1, ... >>> alphaN) op >>> whose defining property is q[alpha1, ... alphaN) op/alpha]. >>> This generalises new_type_definition, which is the special case when >>> Gamma is empty and Q is ?f.TypeDefn P f. >>> >>> Now ?f. TypeDefn p f is equivalent to ?abs.?rep. R P abs rep, >>> where R P abs rep asserts that abs is left-inverse to rep and that >>> rep is left-inverse to abs precisely where P holds (i.e., the properties >>> that new_type_definition gives you of the abstraction and >>> representation functions that HOL Light insists on defining for you). >>> So (*) is equivalent to (**): >>> >>> Gamma |- (?abs.?rep. R P abs rep) => Q >>> >>> By first-order logic, (**) is equiprovable with: >>> >>> Gamma, P = (\r.rep(abs r) = r), (\a.abs(rep a)) = (\a.a) |- Q >>> >>> I had been fiddling around with various not very nice >>> approximations to the above. With your improvements you get >>> something that is relatively easy to understand and is >>> simple enough to propose for serious consideration >>> as a more general replacement for new_type_definition. >>> (Note that it also satisfies you desiderata for naming things: >>> the names of rep and abs above are whatever the user chooses.) >>> >>> Regards, >>> >>> Rob. >>> >>> _______________________________________________ >>> opentheory-users mailing list >>> opentheory-users at gilith.com >>> http://www.gilith.com/mailman/listinfo/opentheory-users >>> >>> >>> _______________________________________________ >>> opentheory-users mailing list >>> opentheory-users at gilith.com >>> http://www.gilith.com/mailman/listinfo/opentheory-users >>> >>> >>> >>> _______________________________________________ >>> opentheory-users mailing list >>> opentheory-users at gilith.com >>> http://www.gilith.com/mailman/listinfo/opentheory-users >>> >> > > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From di.gama at gmail.com Sun Oct 19 01:13:45 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sat, 18 Oct 2014 21:13:45 -0400 Subject: [opentheory-users] Why are theory names showing up as constants in article files? Message-ID: Hello, I'm trying to make sense of the file bool-def-1.10/bool-def-1.10.art, which on line 49 defines [] |- (F = bool-def-1.10), where "bool-def-1.10" is a constant term which has not been previously defined. This is followed by the axiom [] |- (F = (! \p. p)) (118) and finally publishing the theorem [] |- (F = (! \p. p)) on line 122. What kind of constant declaration is this? I don't really understand what the literal string "bool-def-1.10" is doing in all this math, and it strikes me as not being safe either. Later in the same file we have [] |- (T = bool-def-1.10) (191), and [] |- (T = (\p. p = \p. p)) (210); from these we can derive first [] |- T, then we can use 191 and 49 to derive [] |- (T = F) and hence [] |- F, which is not good at all. What is going on here? Mario Carneiro -------------- next part -------------- An HTML attachment was scrubbed... URL: From joe at gilith.com Sun Oct 19 05:36:28 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 18 Oct 2014 22:36:28 -0700 Subject: [opentheory-users] Why are theory names showing up as constants in article files? In-Reply-To: References: Message-ID: Hi Mario, Your question inspired me to update the OpenTheory FAQ: http://www.gilith.com/research/opentheory/faq.html Please take a look at this question http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files and let me know if anything is unclear. Cheers, Joe On Sat, Oct 18, 2014 at 6:13 PM, Mario Carneiro wrote: > Hello, > > I'm trying to make sense of the file bool-def-1.10/bool-def-1.10.art, which > on line 49 defines [] |- (F = bool-def-1.10), where "bool-def-1.10" is a > constant term which has not been previously defined. This is followed by the > axiom [] |- (F = (! \p. p)) (118) and finally publishing the theorem [] |- > (F = (! \p. p)) on line 122. What kind of constant declaration is this? I > don't really understand what the literal string "bool-def-1.10" is doing in > all this math, and it strikes me as not being safe either. Later in the same > file we have [] |- (T = bool-def-1.10) (191), and [] |- (T = (\p. p = \p. > p)) (210); from these we can derive first [] |- T, then we can use 191 and > 49 to derive [] |- (T = F) and hence [] |- F, which is not good at all. What > is going on here? > > Mario Carneiro > > _______________________________________________ > opentheory-users mailing list > opentheory-users at gilith.com > http://www.gilith.com/mailman/listinfo/opentheory-users > From di.gama at gmail.com Sun Oct 19 06:18:02 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 19 Oct 2014 02:18:02 -0400 Subject: [opentheory-users] Why are theory names showing up as constants in article files? In-Reply-To: References: Message-ID: Well, I'm afraid my question is a little more basic, along the lines of why these abbreviated article files are valid under the standard. As I understand it, you would like these name-version.art article files to contain nothing but axiom -> thm directives so that it can function as a listing of theorems without proofs. However, I don't understand the purpose of the defineConst directives that define every constant to be equal to an otherwise-unspecified "bool-def-1.10" constant. It looks like those definitional theorems are just thrown away (using pop) after construction, which makes them even more mysterious, but I'm certain that you could derive a contradiction if you made use of them. This ability to derive a contradiction in a standards-compliant article file is more worrisome. There is no restriction in defineConst that the constant has never been defined before - from this you can easily derive a contradiction using the trick defineConst: [] |- bad = T defineConst: [] |- bad = F sym,trans: [] |- T = F eqMp: [] |- F (where I assume that T and F are defined the usual way and have some basic theorems). Similarly, if you introduce a constant definition via an axiom, then you can't also use defineConst for it, which is to say that no axiom is allowed to use a constant that was defined via defineConst in the article file itself - in these cases you have to also import the definitions of those constants as more axioms. This should fix the inconsistency problem here. Mario On Sun, Oct 19, 2014 at 1:36 AM, Joe Leslie-Hurd wrote: > Hi Mario, > > Your question inspired me to update the OpenTheory FAQ: > > http://www.gilith.com/research/opentheory/faq.html > > Please take a look at this question > > http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files > > and let me know if anything is unclear. > > Cheers, > > Joe > > On Sat, Oct 18, 2014 at 6:13 PM, Mario Carneiro wrote: > > Hello, > > > > I'm trying to make sense of the file bool-def-1.10/bool-def-1.10.art, > which > > on line 49 defines [] |- (F = bool-def-1.10), where "bool-def-1.10" is a > > constant term which has not been previously defined. This is followed by > the > > axiom [] |- (F = (! \p. p)) (118) and finally publishing the theorem [] > |- > > (F = (! \p. p)) on line 122. What kind of constant declaration is this? I > > don't really understand what the literal string "bool-def-1.10" is doing > in > > all this math, and it strikes me as not being safe either. Later in the > same > > file we have [] |- (T = bool-def-1.10) (191), and [] |- (T = (\p. p = \p. > > p)) (210); from these we can derive first [] |- T, then we can use 191 > and > > 49 to derive [] |- (T = F) and hence [] |- F, which is not good at all. > What > > is going on here? > > > > Mario Carneiro > > > > _______________________________________________ > > 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 di.gama at gmail.com Sun Oct 19 06:26:53 2014 From: di.gama at gmail.com (Mario Carneiro) Date: Sun, 19 Oct 2014 02:26:53 -0400 Subject: [opentheory-users] Why are theory names showing up as constants in article files? In-Reply-To: References: Message-ID: If the purpose of the "bool-def-1.10" constant in that file is to indicate where the axioms are coming from, that is more appropriate as a pragma (say ["source", "bool-def-1.10"]) than a defineConst directive. On Sun, Oct 19, 2014 at 2:18 AM, Mario Carneiro wrote: > Well, I'm afraid my question is a little more basic, along the lines of > why these abbreviated article files are valid under the standard. As I > understand it, you would like these name-version.art article files to > contain nothing but axiom -> thm directives so that it can function as a > listing of theorems without proofs. However, I don't understand the purpose > of the defineConst directives that define every constant to be equal to an > otherwise-unspecified "bool-def-1.10" constant. It looks like those > definitional theorems are just thrown away (using pop) after construction, > which makes them even more mysterious, but I'm certain that you could > derive a contradiction if you made use of them. > > This ability to derive a contradiction in a standards-compliant article > file is more worrisome. There is no restriction in defineConst that the > constant has never been defined before - from this you can easily derive a > contradiction using the trick > > defineConst: [] |- bad = T > defineConst: [] |- bad = F > sym,trans: [] |- T = F > eqMp: [] |- F > > (where I assume that T and F are defined the usual way and have some basic > theorems). Similarly, if you introduce a constant definition via an axiom, > then you can't also use defineConst for it, which is to say that no axiom > is allowed to use a constant that was defined via defineConst in the > article file itself - in these cases you have to also import the > definitions of those constants as more axioms. This should fix the > inconsistency problem here. > > Mario > > On Sun, Oct 19, 2014 at 1:36 AM, Joe Leslie-Hurd wrote: > >> Hi Mario, >> >> Your question inspired me to update the OpenTheory FAQ: >> >> http://www.gilith.com/research/opentheory/faq.html >> >> Please take a look at this question >> >> http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files >> >> and let me know if anything is unclear. >> >> Cheers, >> >> Joe >> >> On Sat, Oct 18, 2014 at 6:13 PM, Mario Carneiro >> wrote: >> > Hello, >> > >> > I'm trying to make sense of the file bool-def-1.10/bool-def-1.10.art, >> which >> > on line 49 defines [] |- (F = bool-def-1.10), where "bool-def-1.10" is a >> > constant term which has not been previously defined. This is followed >> by the >> > axiom [] |- (F = (! \p. p)) (118) and finally publishing the theorem [] >> |- >> > (F = (! \p. p)) on line 122. What kind of constant declaration is this? >> I >> > don't really understand what the literal string "bool-def-1.10" is >> doing in >> > all this math, and it strikes me as not being safe either. Later in the >> same >> > file we have [] |- (T = bool-def-1.10) (191), and [] |- (T = (\p. p = >> \p. >> > p)) (210); from these we can derive first [] |- T, then we can use 191 >> and >> > 49 to derive [] |- (T = F) and hence [] |- F, which is not good at all. >> What >> > is going on here? >> > >> > Mario Carneiro >> > >> > _______________________________________________ >> > 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 Sun Oct 19 06:58:22 2014 From: joe at gilith.com (Joe Leslie-Hurd) Date: Sat, 18 Oct 2014 23:58:22 -0700 Subject: [opentheory-users] Why are theory names showing up as constants in article files? In-Reply-To: References: Message-ID: Hi Mario, You're quite right that the purpose of putting the NAME-VERSION in the definition is a way to track the origin of constants, but since the theorems file is only used internally by the opentheory tool to optimize certain calculations there should be no confusion for users. There is no restriction on defineConst in the article standard that the constant has not been defined before, but that check is instead left to the article reader. In most theorem prover implementations redefining a constant is disallowed (perhaps unless it is alpha-equivalent to the existing definition), but the opentheory logical kernel is purely functional and allows it. However, soundness is preserved by storing the definition with the constant, so your hypothetical example would go like this: defineConst: [] |- bad{T} = T defineConst: [] |- bad{F} = F sym,trans: failure, because bad{T} is not alpha-equivalent to bad{F} I recommend ignoring these theorem files, because the functionality they offer is in most cases subsumed by the article file THEORY.art output by the command opentheory info --article -o THEORY.art NAME-VERSION Cheers, Joe On Sat, Oct 18, 2014 at 11:26 PM, Mario Carneiro wrote: > If the purpose of the "bool-def-1.10" constant in that file is to indicate > where the axioms are coming from, that is more appropriate as a pragma (say > ["source", "bool-def-1.10"]) than a defineConst directive. > > > On Sun, Oct 19, 2014 at 2:18 AM, Mario Carneiro wrote: >> >> Well, I'm afraid my question is a little more basic, along the lines of >> why these abbreviated article files are valid under the standard. As I >> understand it, you would like these name-version.art article files to >> contain nothing but axiom -> thm directives so that it can function as a >> listing of theorems without proofs. However, I don't understand the purpose >> of the defineConst directives that define every constant to be equal to an >> otherwise-unspecified "bool-def-1.10" constant. It looks like those >> definitional theorems are just thrown away (using pop) after construction, >> which makes them even more mysterious, but I'm certain that you could derive >> a contradiction if you made use of them. >> >> This ability to derive a contradiction in a standards-compliant article >> file is more worrisome. There is no restriction in defineConst that the >> constant has never been defined before - from this you can easily derive a >> contradiction using the trick >> >> defineConst: [] |- bad = T >> defineConst: [] |- bad = F >> sym,trans: [] |- T = F >> eqMp: [] |- F >> >> (where I assume that T and F are defined the usual way and have some basic >> theorems). Similarly, if you introduce a constant definition via an axiom, >> then you can't also use defineConst for it, which is to say that no axiom is >> allowed to use a constant that was defined via defineConst in the article >> file itself - in these cases you have to also import the definitions of >> those constants as more axioms. This should fix the inconsistency problem >> here. >> >> Mario >> >> On Sun, Oct 19, 2014 at 1:36 AM, Joe Leslie-Hurd wrote: >>> >>> Hi Mario, >>> >>> Your question inspired me to update the OpenTheory FAQ: >>> >>> http://www.gilith.com/research/opentheory/faq.html >>> >>> Please take a look at this question >>> >>> http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files >>> >>> and let me know if anything is unclear. >>> >>> Cheers, >>> >>> Joe >>> >>> On Sat, Oct 18, 2014 at 6:13 PM, Mario Carneiro >>> wrote: >>> > Hello, >>> > >>> > I'm trying to make sense of the file bool-def-1.10/bool-def-1.10.art, >>> > which >>> > on line 49 defines [] |- (F = bool-def-1.10), where "bool-def-1.10" is >>> > a >>> > constant term which has not been previously defined. This is followed >>> > by the >>> > axiom [] |- (F = (! \p. p)) (118) and finally publishing the theorem [] >>> > |- >>> > (F = (! \p. p)) on line 122. What kind of constant declaration is this? >>> > I >>> > don't really understand what the literal string "bool-def-1.10" is >>> > doing in >>> > all this math, and it strikes me as not being safe either. Later in the >>> > same >>> > file we have [] |- (T = bool-def-1.10) (191), and [] |- (T = (\p. p = >>> > \p. >>> > p)) (210); from these we can derive first [] |- T, then we can use 191 >>> > and >>> > 49 to derive [] |- (T = F) and hence [] |- F, which is not good at all. >>> > What >>> > is going on here? >>> > >>> > Mario Carneiro >>> > >>> > _______________________________________________ >>> > 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 >