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