From rote at inf.fu-berlin.de Thu Aug 6 14:30:39 2015
From: rote at inf.fu-berlin.de (=?UTF-8?B?R8O8bnRlciBSb3Rl?=)
Date: Thu, 06 Aug 2015 16:30:39 +0200
Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be
used as a proof verifier
Message-ID: <55C36F8F.6030503@inf.fu-berlin.de>
I am trying to write an article reader in python, mainly to
get an understanding how the steps of a formal proof in HOL look like.
My question concerns the definition of *defineTypeOp*
in the article file format
http://www.gilith.com/research/opentheory/article.html
Since the new constants *abs* and *rep*
appear in a term like "(? (?a. abs (rep a)) = ?a. a)",
they must have some type:
I guess the new type operator op with name n has
type parameters ?1 ... ?k in this order, and
the types of rep and abs are
rep:: n ?1 ... ?k -> b
abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator)
where b is the type of t
Is that true?
In the definition of *opType*, is it required that
the length n of the list equals the k with which
the type-operator "op" has been defined?
(Maybe my question is based on a basic misunderstanding:
Can opentheory be used as a proof verifier?
I.e. If an article file goes through opentheory without
errors, does it mean that the listed "theorems" can be
derived from the "assumptions" (using the OpenTheory derivation rules)?
(I have seen talks about proof verification by transforming opentheory to
dedukti (or rather HOL via opentheory to dedukti) and then verifying the
proof in dedukti. What would be the point of this if this
verification is also fine in opentheory?)
--
G"unter Rote (Germany=49)30-838-75150 (office)
Freie Universit"at Berlin
Institut f"ur Informatik
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5311 bytes
Desc: S/MIME Cryptographic Signature
URL:
From Ramana.Kumar at cl.cam.ac.uk Sat Aug 8 01:02:12 2015
From: Ramana.Kumar at cl.cam.ac.uk (Ramana Kumar)
Date: Sat, 8 Aug 2015 11:02:12 +1000
Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be
used as a proof verifier
In-Reply-To: <55C36F8F.6030503@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
Message-ID:
On 7 August 2015 at 00:30, G?nter Rote wrote:
> I am trying to write an article reader in python, mainly to
> get an understanding how the steps of a formal proof in HOL look like.
>
Sounds like a good idea.
> My question concerns the definition of *defineTypeOp*
> in the article file format
> http://www.gilith.com/research/opentheory/article.html
>
> Since the new constants *abs* and *rep*
> appear in a term like "(? (?a. abs (rep a)) = ?a. a)",
> they must have some type:
>
> I guess the new type operator op with name n has
> type parameters ?1 ... ?k in this order, and
> the types of rep and abs are
> rep:: n ?1 ... ?k -> b
> abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator)
> where b is the type of t
> Is that true?
>
That is correct.
> In the definition of *opType*, is it required that
> the length n of the list equals the k with which
> the type-operator "op" has been defined?
>
Kind of true, but not really. Type operators can be constructed by the
virtual machine even if they have not previously been defined in the same
article. In that case, the type operator will be one of the "external type
operators" (i.e., an input) to the resulting theory. (N.B. if you use
*typeOp* to create a type operator with the same name as one created by
*defineTypeOp*, they won't alias each other; i.e., if you want to use the
type defined by *defineTypeOp* you have to use the TypeOp object that it
returns. Some related previous mails on this point:
http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html.)
However, I think if you are using a type operator whose definition is known
and supply the wrong number of arguments, article processing will fail. Joe
can probably confirm and clarify this.
> (Maybe my question is based on a basic misunderstanding:
> Can opentheory be used as a proof verifier?
> I.e. If an article file goes through opentheory without
> errors, does it mean that the listed "theorems" can be
> derived from the "assumptions" (using the OpenTheory derivation rules)?
>
Yes. The opentheory tool can be used to verify that articles obey the
derivation rules of (OpenTheory's variant of) HOL.
> (I have seen talks about proof verification by transforming opentheory to
> dedukti (or rather HOL via opentheory to dedukti) and then verifying the
> proof in dedukti. What would be the point of this if this
> verification is also fine in opentheory?)
>
There are at least two points to make here:
1. Dedukti verifies proofs in a different logical system, lambda pi modulo
rewriting, in which HOL (e.g., OpenTheory) can be embedded. The idea is
that it could be a place where theories from different logics could be
combined. Thus it makes sense to import into Dedukti, even if you trust the
opentheory-checked version is correct, to allow the connection with other
things in Dedukti.
2. It's always good to have multiple implementations of a proof checker,
since proof checkers can contain bugs but the chances of two very different
implementations having the same bugs are low. (To be clear, proof checkers
don't typically have many bugs, but it's possible.) The opentheory tool
wasn't designed primarily as a proof checker (it has other design goals
too), so it's not the smallest and simplest piece of code doing that job,
hence maybe you would prefer to trust an independent, purpose-built
checker. (I don't think Dedukti is that either though.) The CakeML project
(of which I'm a developer) takes the idea of reducing the need to trust the
proof checker to an extreme: we are working on a proof checker whose
machine-code implementation is itself verified to only accept theories that
are true in all (standard) models of higher-order logic. (Verified in the
sense of having a proof in OpenTheory deriving that fact.)
>
> --
> G"unter Rote (Germany=49)30-838-75150 (office)
> Freie Universit"at Berlin
> Institut f"ur Informatik
>
>
> _______________________________________________
> 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 Sat Aug 8 01:16:09 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Fri, 7 Aug 2015 21:16:09 -0400
Subject: [opentheory-users] defineTypeOp underspecified? / opentheory be
used as a proof verifier
In-Reply-To:
References: <55C36F8F.6030503@inf.fu-berlin.de>
Message-ID:
Hi Gunter and Ramana,
>> I guess the new type operator op with name n has
>> type parameters ?1 ... ?k in this order, and
>> the types of rep and abs are
>> rep:: n ?1 ... ?k -> b
>> abs:: b -> n ?1 ... ?k (using prefix notation for the type-operator)
>> where b is the type of t
>> Is that true?
>
> That is correct.
Thanks for the clarification, I have added a note to defineConst and
defineTypeOp to spell this out:
http://www.gilith.com/research/opentheory/article.html#defineConstCommand
http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand
> However, I think if you are using a type operator whose definition is known
> and supply the wrong number of arguments, article processing will fail. Joe
> can probably confirm and clarify this.
I don't believe this affects soundness, so I regard this as
implementation-dependent behaviour. In the opentheory logical kernel
you can use a defined type operator with the wrong number of arguments
or a defined constant outside of its principal type, but there won't
be much you can prove about such types/terms. The logical kernels of
other systems might throw an exception if you try to construct such
types/terms.
> Yes. The opentheory tool can be used to verify that articles obey the
> derivation rules of (OpenTheory's variant of) HOL.
Agreed, and not just the opentheory tool, but any tool that processes
articles (such as your python tool in development).
Cheers,
Joe
From rote at inf.fu-berlin.de Sun Aug 9 09:02:02 2015
From: rote at inf.fu-berlin.de (=?UTF-8?B?R8O8bnRlciBSb3Rl?=)
Date: Sun, 09 Aug 2015 11:02:02 +0200
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To:
References: <55C36F8F.6030503@inf.fu-berlin.de>
Message-ID: <55C7170A.6080603@inf.fu-berlin.de>
Am 08.08.2015 um 03:16 schrieb Joe Leslie-Hurd:
> Thanks for the clarification, I have added a note to defineConst and
> defineTypeOp to spell this out:
>
> http://www.gilith.com/research/opentheory/article.html#defineConstCommand
> http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand
Thanks. But what is the *principal* type of the new constant?
(And maybe you want to update defineConstList as well?)
Am 15.01.2011 um 03:16 schrieb Joe Leslie-Hurd:
http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html
>> Also, it's not clear whether a "new constant" with the same name as
>> a previously defined constant is allowed. I presume so.
>
> This is left to the system, which must be careful to disallow
>
1. define `c = T`
2. define `c = F`
3. prove `T = F`
>
> I believe all of the HOL theorem provers maintain a symbol table of
> constants, and will not allow redefinitions with the same name. The
> logical kernel of the opentheory tool stores the definition with the
> constant, so will happily allow redefinitions with the same name
> (because the two "c" constants above will be treated as different
> constants).
This puzzles me.
If I now create another "instance" of a constant with name c
(and type bool) by a const+constTerm command, to which
constant from among definitions 1 or 2 (if any) does it
refer to? (More specifically, to which c will it be
alpha-equivalent, when this is for example tested in
the course of eqMP?)
And does the answer change for a constant c that was
"created" before definitions 1 and 2?
best regards : G?nter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5311 bytes
Desc: S/MIME Cryptographic Signature
URL:
From Ramana.Kumar at cl.cam.ac.uk Sun Aug 9 12:49:41 2015
From: Ramana.Kumar at cl.cam.ac.uk (Ramana Kumar)
Date: Sun, 9 Aug 2015 22:49:41 +1000
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To: <55C7170A.6080603@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
Message-ID:
On 9 August 2015 at 19:02, G?nter Rote wrote:
> Am 08.08.2015 um 03:16 schrieb Joe Leslie-Hurd:
> > Thanks for the clarification, I have added a note to defineConst and
> > defineTypeOp to spell this out:
> >
> >
> http://www.gilith.com/research/opentheory/article.html#defineConstCommand
> >
> http://www.gilith.com/research/opentheory/article.html#defineTypeOpCommand
>
> Thanks. But what is the *principal* type of the new constant?
>
HOL constants are polymorphic. But the type of every instance of a
particular constant is a type instance of one particular type. That one
type is the principal type of the constant.
> (And maybe you want to update defineConstList as well?)
>
Yes, I think an analogous note would make sense.
>
> Am 15.01.2011 um 03:16 schrieb Joe Leslie-Hurd:
> http://www.gilith.com/pipermail/opentheory-users/2011-January/000080.html
> >> Also, it's not clear whether a "new constant" with the same name as
> >> a previously defined constant is allowed. I presume so.
> >
> > This is left to the system, which must be careful to disallow
> >
> 1. define `c = T`
> 2. define `c = F`
> 3. prove `T = F`
> >
> > I believe all of the HOL theorem provers maintain a symbol table of
> > constants, and will not allow redefinitions with the same name. The
> > logical kernel of the opentheory tool stores the definition with the
> > constant, so will happily allow redefinitions with the same name
> > (because the two "c" constants above will be treated as different
> > constants).
>
> This puzzles me.
> If I now create another "instance" of a constant with name c
> (and type bool) by a const+constTerm command, to which
> constant from among definitions 1 or 2 (if any) does it
> refer to?
Neither. The only way to get the constants from the definitions in 1 and 2
is as the objects returned by the definition commands.
> (More specifically, to which c will it be
> alpha-equivalent, when this is for example tested in
> the course of eqMP?)
>
(neither)
> And does the answer change for a constant c that was
> "created" before definitions 1 and 2?
>
No. (I'm not 100% confident of these three answers; Joe will know best.)
>
> best regards : G?nter
>
>
> _______________________________________________
> 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 Aug 9 14:13:30 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sun, 9 Aug 2015 10:13:30 -0400
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To:
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
Message-ID:
>> (And maybe you want to update defineConstList as well?)
>
> Yes, I think an analogous note would make sense.
Done:
http://www.gilith.com/research/opentheory/article.html#defineConstListCommand
>> If I now create another "instance" of a constant with name c
>> (and type bool) by a const+constTerm command, to which
>> constant from among definitions 1 or 2 (if any) does it
>> refer to?
>
> Neither. The only way to get the constants from the definitions in 1 and 2
> is as the objects returned by the definition commands.
Ramana has this right. And to answer your follow-up question, since
the opentheory logical kernel is purely functional it doesn't matter
which order definitions happen.
Cheers,
Joe
From rote at inf.fu-berlin.de Sun Aug 9 14:32:31 2015
From: rote at inf.fu-berlin.de (=?windows-1252?Q?G=FCnter_Rote?=)
Date: Sun, 09 Aug 2015 16:32:31 +0200
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To:
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
Message-ID: <55C7647F.60304@inf.fu-berlin.de>
> http://www.gilith.com/research/opentheory/article.html#defineConstListCommand
>
>>> If I now create another "instance" of a constant with name c
>>> (and type bool) by a const+constTerm command, to which
>>> constant from among definitions 1 or 2 (if any) does it
>>> refer to?
>>
>> Neither. The only way to get the constants from the definitions in 1 and 2
>> is as the objects returned by the definition commands.
>
> Ramana has this right. And to answer your follow-up question, since
> the opentheory logical kernel is purely functional it doesn't matter
> which order definitions happen.
>
O.K. (But it appears more like a object-oriented feature to me:
nothing is equal unless one explicitly defines it to be equal).
Two more questions:
1) If I create several constants with name c
(and the same type bool) by a sequence of const+constTerm commands,
are they equal (alpha-equivalent) to each other?
(Like "T" and "T"?)
2) If I define two constants c with the defineConst command
with the *same* definition, are they considered equal?
In any case, I think the documentation needs some clarification,
in particular here:
const
Higher order logic constants, such as T and =.
*Constants are identified by name*
It seems rather that the name acts merely as a comment in the above cases.
regards : G?nter
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5311 bytes
Desc: S/MIME Cryptographic Signature
URL:
From joe at gilith.com Sun Aug 9 15:03:27 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sun, 9 Aug 2015 11:03:27 -0400
Subject: [opentheory-users] Definition of "term" (plus other issues)
In-Reply-To: <55C72710.3020603@inf.fu-berlin.de>
References: <55C72710.3020603@inf.fu-berlin.de>
Message-ID:
[cc'ing the OpenTheory mailing list]
Hi Gunter,
Thank you very much for suggesting these clarifications. It is always
useful to hear what is confusing to people reading the article
standard for the first time.
I have incorporated all of your suggestions into the standard:
http://www.gilith.com/research/opentheory/article.html
Please take a look and let me know if that would have helped you.
Cheers,
Joe
On Sun, Aug 9, 2015 at 6:10 AM, G?nter Rote wrote:
> Dear Joe.
> Here is another thing which I did not learn explicitly from the
> specification but the "hard way"
>
> 1. I think the following definition is misleading, in particular the
> examples.
>
> term
> Higher order logic terms, such as 13 and ?x. x. Terms are
> ?-equivalent if they are equal up to a consistent renaming of bound
> variables, so ?x y. p x y is ?-equivalent to ?y x. p y x but not to ?y
> x. p x y.
>
> terms are not just the expression, but they always come with a type.
> the examples might be
> 13:bool->bool
> or
> ?x. x: bool
> or perhaps something more instructive
> ?x. f x: (a->int) ->(b->int)
>
> 2. Another clarification that might be worth mentioning: (I think this
> issue has come up in the mailing list).
>
> when you write ? ? ?, you are referring to the binary type operator
> with name '->', and not with name "?", (despite utf-8 input)
> (I guess in prettyprinted html output they would both be rendered
> identically?
>
> 3. in appTerm and appThm
> Constraint: The term f must have a type of the form ? ? ?, and the
> term x must have a matching type ?.
>
> I guess when you write "x must have a *matching* type ?." you just mean
> "x must have type ?." I was wondering whether "matching" could have
> been meant in some technical sense such as matching after renaming of type
> variables or even something more elaborate such as unification.
>
> (And, the resulting term f x will (obviously) have type ?.)
>
> 4. maybe you want to say something about the result type in absTerm
>
> With best regards : G?nter
>
From joe at gilith.com Sun Aug 9 18:56:35 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sun, 9 Aug 2015 14:56:35 -0400
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To: <55C7647F.60304@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
Message-ID:
Hi Gunter,
> O.K. (But it appears more like a object-oriented feature to me:
> nothing is equal unless one explicitly defines it to be equal).
I'd highly encourage that view: if you only build objects once and
store them in a dictionary if they are used multiple times, then
equality will be nice and boring.
> Two more questions:
> 1) If I create several constants with name c
> (and the same type bool) by a sequence of const+constTerm commands,
> are they equal (alpha-equivalent) to each other?
> (Like "T" and "T"?)
Yes: these will be equal.
> 2) If I define two constants c with the defineConst command
> with the *same* definition, are they considered equal?
This is implementation-dependent. Some theorem proving systems will
not allow you to define two constants with the same name, some will
allow it if the definitions are equal, and some (like opentheory) will
be fine with it and will give equal constants if the definitions are
equal.
> In any case, I think the documentation needs some clarification,
> in particular here:
>
> const
> Higher order logic constants, such as T and =.
> *Constants are identified by name*
>
> It seems rather that the name acts merely as a comment in the above cases.
I agree that this is unclear, in the light of the above examples. For
now I have removed the confusing part you have highlighted.
Cheers,
Joe
From rote at inf.fu-berlin.de Thu Aug 13 14:15:59 2015
From: rote at inf.fu-berlin.de (=?windows-1252?Q?G=FCnter_Rote?=)
Date: Thu, 13 Aug 2015 16:15:59 +0200
Subject: [opentheory-users] definition of "new" constants? / processing
of packages
In-Reply-To: <55C861C3.1090608@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
<55C861C3.1090608@inf.fu-berlin.de>
Message-ID: <55CCA69F.7050605@inf.fu-berlin.de>
On 10.08.2015 10:33, G?nter Rote wrote:
> Thanks. I'll go with this in the implementation. (maybe issue a warning)
> Although it is somewhat baroque.
> Two constant terms are considered equal if
> (a) they were both generated by constTerm commands and
> have the same name and type
> (b) they were both generated by defineConst commands
> with the same name and definition (including type)
>
and (c) they are the abs or rep constants that were
defined in the same defineTypeOp statement.
>
> I am beginning to wonder how different constants with the same name
> will survive the interface between several article files in
> a safe and sound way.
Dear Joe!
I gave it a try, and I found that it is forbidden to use
two constants with different definitions and the same name
in exported theorems (using thm) and perhaps also assumptions (using axiom):
This makes perfect sense for a sound proof checker,
but it should be part of the specification.
====================
>opentheory info two-const-conflict.art
FATAL ERROR: opentheory failed:
different constants named "C"
====================
When opentheory processes a theory, does it read all theory article files
on which it depends?
Or is there a way that it just needs to read the theorems from
other packages that it uses?
(In trying to understand how the interface between theories works,
I have looked at
http://www.gilith.com/research/opentheory/theory.html
and the paper
"Composable Packages for Higher Order Logic Theories", which is outdated
in this respect.
(Incidentally, your version of the Schr?der?Bernstein theorem
might require the axiom of choice, see
https://en.wikipedia.org/wiki/Schr%C3%B6der%E2%80%93Bernstein_theorem
Here are some questions:
What is the checksum entry?
I can somehow guess what the entry
show: "Data.Bool"
in the .thm file means, but it is not completely clear.
In particular, what happens when there are several "show: " lines?
Is there a way to eventually look at the theorems that are proved
in detail in an unambiguous format with all type information? (other than the html
format with mouse-over?)
Best regards :
--
G"unter Rote (Germany=49)30-838-75150 (office)
Freie Universit"at Berlin -75103 (secretary)
Institut f"ur Informatik FAX (49)30-838-75192
Takustrase 9, D-14195 Berlin, GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5311 bytes
Desc: S/MIME Cryptographic Signature
URL:
From ramana at member.fsf.org Fri Aug 14 06:09:27 2015
From: ramana at member.fsf.org (Ramana Kumar)
Date: Fri, 14 Aug 2015 16:09:27 +1000
Subject: [opentheory-users] definition of "new" constants? / processing
of packages
In-Reply-To: <55CCA69F.7050605@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
<55C861C3.1090608@inf.fu-berlin.de> <55CCA69F.7050605@inf.fu-berlin.de>
Message-ID:
Dear G?nter,
I can answer some but not all of your questions, and do so below.
On 14 August 2015 at 00:15, G?nter Rote wrote:
> When opentheory processes a theory, does it read all theory article files
> on which it depends?
>
opentheory would need to know the logical content (the theory inputs and
outputs) of the dependencies, in order to calculate the theory inputs and
outputs of the theory being processed. Whether it figures these out by
processing the dependencies or using some caches, I'm not sure.
> Or is there a way that it just needs to read the theorems from
> other packages that it uses?
>
I suspect there is a cache, but Joe would know.
> I can somehow guess what the entry
> show: "Data.Bool"
> in the .thm file means, but it is not completely clear.
> In particular, what happens when there are several "show: " lines?
>
Each "show: " line adds another bit of namespace that won't need to be
printed. I agree that their exact format and effect is a bit mysterious,
though.
> Is there a way to eventually look at the theorems that are proved
> in detail in an unambiguous format with all type information? (other than
> the html
> format with mouse-over?)
>
I would say that the article itself is this "unambiguous format". If you
want to see a term in any other format, you can write an article parser
that will build the term and then print it however you like.
>
> Best regards :
> --
> G"unter Rote (Germany=49)30-838-75150 (office)
> Freie Universit"at Berlin -75103 (secretary)
> Institut f"ur Informatik FAX (49)30-838-75192
> Takustrase 9, D-14195 Berlin, GERMANY
>
>
>
> _______________________________________________
> 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 Sat Aug 15 17:30:18 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sat, 15 Aug 2015 10:30:18 -0700
Subject: [opentheory-users] definition of "new" constants? / processing
of packages
In-Reply-To: <55CCA69F.7050605@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
<55C861C3.1090608@inf.fu-berlin.de>
<55CCA69F.7050605@inf.fu-berlin.de>
Message-ID:
Hi Gunter,
> I gave it a try, and I found that it is forbidden to use
> two constants with different definitions and the same name
> in exported theorems (using thm) and perhaps also assumptions (using axiom):
> This makes perfect sense for a sound proof checker,
> but it should be part of the specification.
I agree, although I'm not sure whether it's part of the article spec
or the theory spec. If you're reading an article inside a theorem
prover it might be ok to have two different constants with the same
name (depending on the design of the logical kernel), so I hesitate to
forbid it for articles.
However, in the context of a theory constants are imported by name, so
there cannot be two constants in scope with the same name. So perhaps
the theory spec is the place to forbid this:
http://www.gilith.com/research/opentheory/theory.html
> ====================
>>opentheory info two-const-conflict.art
>
> FATAL ERROR: opentheory failed:
> different constants named "C"
> ====================
The opentheory tool reads articles inside an implicit "article block"
(see the theory spec), which is why your test article explodes.
> When opentheory processes a theory, does it read all theory article files
> on which it depends?
> Or is there a way that it just needs to read the theorems from
> other packages that it uses?
It just reads the statement of the theorems generated when the package
is installed. See this FAQ:
http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files
> What is the checksum entry?
The checksum is the package checksum. The opentheory tool allows you
to specify a package checksum when you install packages, to ensure you
are getting the exact package you want.
> I can somehow guess what the entry
> show: "Data.Bool"
> in the .thm file means, but it is not completely clear.
> In particular, what happens when there are several "show: " lines?
These are namespace abbreviations, as mentioned in the example package file:
http://www.gilith.com/research/opentheory/example-1.0.html
When printing names the first show: line that matches a prefix of the
namespace gets applied, and the name is either rewritten (if the line
is show: "X" as "Y") or abbreviated (if the line is show: "X").
> Is there a way to eventually look at the theorems that are proved
> in detail in an unambiguous format with all type information? (other than the html
> format with mouse-over?)
In machine-readable format you can look at the generated theorem files
described above. In human-readable format you can see types using:
$ opentheory --show-types info --theory natural-def
and you can additionally bypass any show: declarations by converting
to an article first:
$ opentheory info --article natural-def | opentheory --show-types info article:-
Cheers,
Joe
From joe at gilith.com Sat Aug 15 17:35:01 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sat, 15 Aug 2015 10:35:01 -0700
Subject: [opentheory-users] format of opentheory parameters
In-Reply-To: <55CDF3F6.1040201@inf.fu-berlin.de>
References: <55CDF3F6.1040201@inf.fu-berlin.de>
Message-ID:
[cc'ing the opentheory mailing list]
Hi Gunter,
> INPUT is one of the following:
> - A package: NAME-VERSION or NAME (for the latest version)
> - A theory source file: FILE.thy or theory:FILE
> - ...
What this meant to say (and I agree it's not crystal clear) is that if
the file has an extension .thy it will be treated by default as a
theory file, but you can treat any other file as a theory file by
prepending theory: to the name of the file. So if you have a theory
file two_c.thy you can process it just using
opentheory info two_c.thy
but if you have a theory file called two_c.txt then you will need to
prepend theory: for the opentheory tool to properly interpret it:
opentheory info theory:two_c.txt
>>opentheory info two_c.thy
> triggers
> opentheory: unknown type of input: two_c.thy
In the light of the above, this error is very strange. What platform are you on?
Cheers,
Joe
From joe at gilith.com Sun Aug 16 03:31:01 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sat, 15 Aug 2015 20:31:01 -0700
Subject: [opentheory-users] format of opentheory parameters
In-Reply-To: <55CF7A71.7040802@inf.fu-berlin.de>
References: <55CDF3F6.1040201@inf.fu-berlin.de>
<55CF7A71.7040802@inf.fu-berlin.de>
Message-ID:
[cc'ing the opentheory mailing list]
Hi Gunter,
I've just finished investigating this issue, and discovered that the
opentheory tool had some hidden constraints:
1. For a FILE.thy to be recognized as a theory, FILE had to be a valid
package name.
2. For a FILE.tgz to be recognized as a tarball, FILE had to be a
valid package name-version.
These hidden constraints are simply confusing and serve no useful
purpose that I can discover, so I have removed them and released a new
version of the opentheory tool.
Your original invocation
opentheory info two_c.thy
should now work just fine (even though two_c is not a valid package name).
Thank you for the bug report,
Joe
On Sat, Aug 15, 2015 at 10:44 AM, G?nter Rote wrote:
> Am 15.08.2015 um 19:35 schrieb Joe Leslie-Hurd:
>> [cc'ing the opentheory mailing list]
>>
>> Hi Gunter,
>>
>>> INPUT is one of the following:
>>> - A package: NAME-VERSION or NAME (for the latest version)
>>> - A theory source file: FILE.thy or theory:FILE
>>> - ...
>>
>> What this meant to say (and I agree it's not crystal clear) is that if
>> the file has an extension .thy it will be treated by default as a
>> theory file, but you can treat any other file as a theory file by
>> prepending theory: to the name of the file. So if you have a theory
>> file two_c.thy you can process it just using
>>
>> opentheory info two_c.thy
>>
>> but if you have a theory file called two_c.txt then you will need to
>> prepend theory: for the opentheory tool to properly interpret it:
>
> Yes, that is how I understood it.
>
>> opentheory info theory:two_c.txt
>>
>>>> opentheory info two_c.thy
>>> triggers
>>> opentheory: unknown type of input: two_c.thy
>>
>> In the light of the above, this error is very strange. What platform are you on?
>
> Gnu/Linux, more specifically Ubuntu 12.04
> I have compiled opentheory with the mlton compiler.
>
>
From joe at gilith.com Mon Aug 17 04:38:14 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Sun, 16 Aug 2015 21:38:14 -0700
Subject: [opentheory-users] definition of "new" constants?
In-Reply-To: <55CF8910.2050908@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
<55C861C3.1090608@inf.fu-berlin.de>
<55CCA69F.7050605@inf.fu-berlin.de>
<55CF8910.2050908@inf.fu-berlin.de>
Message-ID:
[cc'ing the opentheory mailing list]
Hi Gunter,
> Somewhere it should be specified what the list of
> external type operators, external constants etc.
> of an article file are. (which would have to
> refer to the state of the virtual machine)
I have introduced the concept of external and defined symbols in the
article spec:
http://www.gilith.com/research/opentheory/article.html
See the explanations of constants and type operators, and also the
commands typeOp, const and axiom.
I have also added some verbiage at the bottom of the Virtual Machine
section describing the constraint that there should not be different
symbols with the same name in exported theorems.
Thank you again for your comments: every new person who reads the
standard and gives feedback improves it for everyone.
> By the way, I made a systematic catalog of the
> article file commands:
> http://page.mi.fu-berlin.de/rote/Software/OpenTheory/opentheory-commands.html
This is an excellent document, thank you for creating it. If it is in
a permanent location would you mind me linking to it from the
OpenTheory project page?
> I noted that opentheory seems to have a lot of "built-in"
> prettyprinting, like 0 for "Number.Natural.zero".
> Or is there a mechanism to define such transformations?
There is a certain amount of built-in pretty-printing intended to
support the standard theory library, but there is no mechanism to
extend it further.
Cheers,
Joe
From joe at gilith.com Fri Aug 21 05:14:16 2015
From: joe at gilith.com (Joe Leslie-Hurd)
Date: Thu, 20 Aug 2015 22:14:16 -0700
Subject: [opentheory-users] definition of "new" constants? /
defineTypeOp rule
In-Reply-To: <55D4A7DC.3060701@inf.fu-berlin.de>
References: <55C36F8F.6030503@inf.fu-berlin.de>
<55C7170A.6080603@inf.fu-berlin.de>
<55C7647F.60304@inf.fu-berlin.de>
<55C861C3.1090608@inf.fu-berlin.de>
<55CCA69F.7050605@inf.fu-berlin.de>
<55CF8910.2050908@inf.fu-berlin.de>
<55D4A7DC.3060701@inf.fu-berlin.de>
Message-ID:
[cc'ing opentheory mailing list]
Hi Gunter,
> (It is fine it you want to Cc the mailing list in your replies; I just don't want to
> create too much traffic.
The purpose of the OpenTheory mailing list is to answer people's
questions and discuss OpenTheory topics, so please don't worry about
creating traffic on the list. Also, I prefer to use the mailing list
for OpenTheory emails as a public record of the discussions and so
other people also have the chance to answer questions.
>> I have also added some verbiage at the bottom of the Virtual Machine
>> section describing the constraint that there should not be different
>> symbols with the same name in exported theorems.
>
> 1. "must not reference two different constants that have the same name."
>
> This is stricter than what the opentheory tool currently allows?
> (I prefer it that way.)
It is not intended to be stricter. The set of constants contained in
the exported theorems must have the property that different constants
have different names, which I believe is what the opentheory tool
requires. Have you encountered a situation that violates this but is
permitted by the opentheory tool?
> "The same constraint also holds for the set of assumptions ?".
> For clarity, I would put it right at the beginning
>
> "Constraint: The set of theorems ? and assumptions ? must not ..."
>
> (otherwise it looks as if one constant in ? and a different constant in ? were o.k.
Actually there's nothing wrong with this scenario: it's just some
sloppy programming in the opentheory tool that generated an error in
this case. I've just released a new version of the opentheory tool
that permits this scenario (with a warning) and added a new test case
that demonstrates it:
$ opentheory info test/articles/example12.art
WARNING: 2 different constants named c
1 external type operator: bool
1 external constant: c
1 assumption:
|- c
1 defined constant: c
1 theorem:
|- c
> 3. another question: I don't completely see through the definetypeop
> rule.
>
> a) Is the role of Thm(? ? t) only to specify the type of t?
The main purpose is to prove that the predicate \phi is non-empty,
which is a required condition of every higher order logic type.
> b) When I look at the *list* type operator
> in list-def-1.63.art
> it is defined with the type of t being bool.
These files are just the theorem caches for a package, they do not
define symbols properly. They are really only intended for internal
use to optimize theory dependency computations:
http://www.gilith.com/research/opentheory/faq.html#what-are-theorem-files
I recommend simply ignoring these files: they are a great source of confusion.
> c) Is there an example where rep and abs and the theorems are not
> thrown away?
My standard pattern is to define a type, use the abs/rep constants and
bijection theorems to define some other constants and prove some
characteristic theorems about the new type, and then export these
characteristic theorems from the theory. This effectively hides the
primitive abs/rep constants returned from defineTypeOp inside the
theory abstraction.
> d) Where can I find some background information on the
> defineTypeOp rule of the OpenTheory logical kernel?
> (PS. I found some explanation on p. 81 in
> https://who.rocq.inria.fr/Ali.Assaf/research/thesis.pdf
Take a look at the HOL4 "Logic" manual:
http://hol-theorem-prover.org/documentation.html
Section 2.5.4 describes type definition.
Cheers,
Joe
From ramana at member.fsf.org Mon Aug 31 05:24:29 2015
From: ramana at member.fsf.org (Ramana Kumar)
Date: Mon, 31 Aug 2015 15:24:29 +1000
Subject: [opentheory-users] importer for Isabelle
In-Reply-To:
References:
Message-ID:
Hi Brian,
Could I trouble you to look for a copy of your OpenTheory-related code for
Isabelle? I'd like to see if I can get it working.
Oh, actually I just found this link:
http://www4.in.tum.de/~huffman/cgi-bin/repos.cgi/OpenTheory
So, I can get started with that, but if you have any comments or ideas they
could probably still be helpful :)
Cheers,
Ramana
On 6 July 2015 at 20:54, Ramana Kumar wrote:
> Yes, if it works (or is close to working) I would like to get it
> incorporated into the Isabelle codebase. I'm not yet sure how to contribute
> things to Isabelle, but I imagine I'll find out within the next few months.
>
> On 23 May 2015 at 15:52, Brian Huffman wrote:
>
>> I've hardly looked at it since I wrote it. It was never incorporated
>> into the Isabelle codebase. I suppose it would probably work with the
>> latest Isabelle, because it uses only the low-level proof kernel api,
>> which doesn't change much any more.
>>
>> I'll have to look around to see where I have a copy of the source
>> code; that was a couple of computers ago. Did you want to try to do
>> something with it?
>>
>> - Brian
>>
>>
>> On Sat, May 23, 2015 at 5:13 AM, Ramana Kumar
>> wrote:
>> > Hi Brian,
>> >
>> > What's the status of your OpenTheory importer? Does it work with the
>> > latest Isabelle? Was it incorporated into the main code base?
>> >
>> > Cheers,
>> > Ramana
>> >
>> > On 15 April 2011 at 17:34, Brian Huffman wrote:
>> >> On Thu, Apr 14, 2011 at 7:03 PM, Joe Hurd wrote:
>> >>> Hi Brian,
>> >>>
>> >>> That is really great work! Am I right in thinking you can import the
>> >>> parser-1.5 article binding all the input symbols and axioms to
>> >>> existing ones in Isabelle? I would have guessed that Isabelle type
>> >>> classes would have managed to get in the way at some point, but
>> >>> perhaps this would only be for converting Isabelle proofs to
>> >>> OpenTheory format?
>> >>
>> >> Yes, each of the input constants of the article is mapped to a
>> >> pre-existing Isabelle constant. Some of these existing Isabelle
>> >> constants happen to be overloaded, but that doesn't cause any
>> >> problems. This mapping of constant names does not even need to be
>> >> one-to-one; for example, I imagine that "Number.Natural.+" and
>> >> "Number.Integer.+" would map to the same overloaded "plus" constant in
>> >> Isabelle.
>> >>
>> >> Of course, exporting proofs from Isabelle is a completely different
>> story.
>> >>
>> >>> You mentioned that you prove a lot of theorems that the OpenTheory
>> >>> article relies on, but it seems you could reduce this by processing a
>> >>> set of OpenTheory packages that don't make any definitions. When I was
>> >>> designing the standard theory library I tried to isolate packages that
>> >>> made definitions and have them export just a minimal theorem interface
>> >>> - most of the theorems are proved in packages that make no definitions
>> >>> and so can be safely run to populate the [opentheory] set of theorems.
>> >>
>> >> Your idea of keeping definitions in separate, minimal modules is a
>> >> good design. I'm sure I could have greatly reduced the number of
>> >> [opentheory] lemmas that I needed by finding the right additional
>> >> article files to import; I was just too lazy to figure out how the
>> >> packages were organized.
>> >>
>> >>>> The importer should also extend these tables whenever it defines a
>> new
>> >>>> constant or type, but I haven't implemented this yet. Another nice
>> >>>> feature would be a way for users to influence how the importer
>> chooses
>> >>>> names for newly-defined constants and types. Right now it takes the
>> >>>> names directly from the strings in the article file, which isn't so
>> >>>> nice for names like "HOLLight._dest_rec" (Isabelle's parser can't
>> >>>> handle names that start with underscores).
>> >>>
>> >>> You should find that constants and type operators with names like this
>> >>> are never exported from a theory (i.e., never appear in exported
>> >>> theorems), so it's perfectly safe to normalize their names to
>> >>> something more acceptable to Isabelle. They are `local definitions'
>> >>> that are used only in proofs.
>> >>
>> >> Actually, it seems like it would be safe to rename *any* constant
>> >> (whether exported or not) to any name that I want in Isabelle, as long
>> >> as the importer keeps track of the name mapping so that later imports
>> >> can use the same names.
>> >>
>> >> I suppose I should write an "import_name" function that converts from
>> >> OpenTheory names to Isabelle-friendly ones. It would be nice to
>> >> parameterize this by a list of user-specified exceptions to the
>> >> mapping, so you could say something like, "import this article, but
>> >> when you define constant 'foo', call it 'bar' instead."
>> >>
>> >>>> Once I clean up the code, I'm not sure what I should do with it... I
>> >>>> suppose I could add it to the Isabelle repo, but I'm not sure if I
>> >>>> want to advertise to Munich crowd that I've been doing all this work
>> >>>> that is unrelated to finishing my thesis :)
>> >>>
>> >>> I would very much like to see it live on in some fashion - my hope is
>> >>> that more and more theories will be converted to OpenTheory packages,
>> >>> and your code could be used to import them into Isabelle in a
>> >>> principled way.
>> >>
>> >> I suppose I'll add it to the Isabelle distribution at some point,
>> >> maybe after I finish writing my thesis. In the meantime, I guess I can
>> >> post the code to the list, so it will be archived and people can try
>> >> it out.
>> >>
>> >> - Brian
>> >>
>> >> _______________________________________________
>> >> opentheory-users mailing list
>> >> opentheory-users at gilith.com
>> >> http://www.gilith.com/mailman/listinfo/opentheory-users
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: