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