From ali.assaf at inria.fr Thu Jun 28 08:33:51 2012
From: ali.assaf at inria.fr (Ali Assaf)
Date: Thu, 28 Jun 2012 10:33:51 +0200 (CEST)
Subject: [opentheory-users] Questions about the standard library packages
Message-ID: <446385352.6937984.1340872431222.JavaMail.root@inria.fr>
Hello,
I am working on a translation from OpenTheory to Dedukti ( http://www.lix.polytechnique. fr/dedukti/ ), a proof system close to the LF and Coq family. I have some questions regarding the packaging of some theories in the standard library.
1. Our biggest obstacle right now is inductive type definitions. It turns out it is very expensive to type-check the complex machanisms of inductive type definitions the way they are currently implemented in HOL (and hence in OpenTheory). However, these mechanisms are hidden in the packages that use them (e.g. in list-def, option-def, sum-def) and therefore reappear in each of them, resulting in bloated packages. Is there any reason why inductive type definitions have not been formalized in a separate package, on which the theories using them (list, option, sum, etc.) depend on?
2. Why are some constant definitions hidden (e.g. the empty list [] and the list constructor (::)) while others are not (e.g. boolean connectives)?
3. The packaging of real numbers is a bit odd. It is only split in two, very unbalanced packages, real-def and real-thm, and most of the theory is squeezed into the first one, resulting in a huge monolithic package (compare this to the theory of natural numbers). Is this intended or is it still a work in progress?
Regards,
Ali Assaf
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
From joe at gilith.com Fri Jun 29 03:35:25 2012
From: joe at gilith.com (Joe Hurd)
Date: Thu, 28 Jun 2012 20:35:25 -0700
Subject: [opentheory-users] Questions about the standard library packages
In-Reply-To: <446385352.6937984.1340872431222.JavaMail.root@inria.fr>
References: <446385352.6937984.1340872431222.JavaMail.root@inria.fr>
Message-ID:
Hi Ali,
> I am working on a translation from OpenTheory to Dedukti
> (http://www.lix.polytechnique.fr/dedukti/), a proof system close to the LF
> and Coq family. I have some questions regarding the packaging of some
> theories in the standard library.
Sounds cool - I'd be happy to see an interchange of theories between
the HOL family and Dedukti.
> 1. Our biggest obstacle right now is inductive type definitions. It turns
> out it is very expensive to type-check the complex machanisms of inductive
> type definitions the way they are currently implemented in HOL (and hence in
> OpenTheory). However, these mechanisms are hidden in the packages that use
> them (e.g. in list-def, option-def, sum-def) and therefore reappear in each
> of them, resulting in bloated packages. Is there any reason why inductive
> type definitions have not been formalized in a separate package, on which
> the theories using them (list, option, sum, etc.) depend on?
This is the difference between "static linking" of one theory within
another (as is currently the case in these theories) and "dynamic
linking" (carving out a common theory that they depend on). Just as
with software, there are advantages and disadvantages to both methods
of linking:
Static linking: fewer dependencies to manage; no re-use possible.
Dynamic linking: must construct out a clean common theory that lives
in the standard namespace; can re-use to create more compact theories
that depend on it.
Right now no one has expended the effort to carve out a clean theory
of inductive definitions, so it is in the default state of being
statically linked into any theory that uses them.
> 2. Why are some constant definitions hidden (e.g. the empty list [] and the
> list constructor (::)) while others are not (e.g. boolean connectives)?
There is no special significance of a definition theorem in a theory
export - it is up to the theory author to choose what theorems to
export that refer to constants and type operators defined in a theory.
Since there is very little machinery available to clean up the
definitions made in bool-def, the definition theorems are exported
"as-is". In later theories forms such as
|- !x. c x = tm[x]
are exported rather than the primitive definition form
|- c = \x. tm[x]
for aesthetic reasons.
> 3. The packaging of real numbers is a bit odd. It is only split in two, very
> unbalanced packages, real-def and real-thm, and most of the theory is
> squeezed into the first one, resulting in a huge monolithic package (compare
> this to the theory of natural numbers). Is this intended or is it still a
> work in progress?
This is most definitely a work in progress. real-thm currently just
has a couple of trivial theorems in it, while real-def contains the
entire HOL Light construction of the real numbers from the natural
numbers, resulting in quite a big theory:
$ opentheory info --inference real-def
Primitive inferences:
eqMp ............ 11,710
subst ............ 9,691
appThm ........... 8,985
deductAntisym .... 5,501
refl ............. 3,469
absThm ........... 1,829
betaConv ......... 1,596
assume ............. 428
axiom .............. 151
defineConst ......... 36
defineTypeOp ......... 3
Total ........... 43,399
Cheers,
Joe