Restructure the theory files
to make both deep and shallow interpretation available.
By default, the ontologies use the shallow interpretation
by relying on Isa_COL which uses the shallow interpretation.
Following the explanation given by Dominique (cf. email),
we must choose which representation of the prop of the theorem
we would like to reify:
- the prop of the theorem given by "Thm.prop_of thm" has not been
processed and then its schematic variables still have their sorts
- the prop of the PThm accessible in the proof given by
"Thm.proof_of thm" has been processed and do not
have anymore its sorts which have been replaced by explicit
"OFCLASS(...)" assumptions.
The choice will have consequences for the reify_proofterm function:
PAxm and PThm uses the tyinst typ which have sorts:
type_synonym tyinst = "(variable × sort) × typ"
It seems that if we use the processed prop, the sort list
will always be empty, even if the prop is logically equivalent to the
unprocessed one (given by "Thm.prop_of thm").
Also the proofterm will not be the same (see examples)
Another point: I use the Proof_Syntax.standard_proof_of function
to get the proof for the DOF thm datatype.
(* Proof_Syntax.standard_proof_of reconstructs the proof and seems to rewrite
the option arguments (with a value NONE) of the proof datatype constructors,
at least for PAxm, with "SOME (typ/term)",
allowing us the use the projection function "the".
Maybe the function can deal with
all the option types of the proof datatype constructors*)
Maybe it is not what we want and we want to use Proofterm.proof_of,
but then we'll have to deal with the option types of the
proof datatype constructors, i.e., we must know
how to rewrite the option with value NONE.
For PAxm, a typ list option, after the Proof_Syntax.standard_proof_of
function, will become SOME ["?'a::{}"]:
val standard_proof =
PAxm ("Pure.symmetric",
Const ("Pure.imp", "prop ⇒ prop ⇒ prop") $
(Const ("Pure.eq", "?'a::{} ⇒ ?'a::{} ⇒ prop") $
Var (("x", 0), "?'a::{}") $ Var (("y", 0), "?'a::{}")) $
(Const ("Pure.eq", "?'a::{} ⇒ ?'a::{} ⇒ prop") $
Var (("y", 0), "?'a::{}") $ Var (("x", 0), "?'a::{}")),
SOME ["?'a::{}"]) %
NONE % NONE:
proof
See the examples in Test_Reification.thy
Support invariants on attributes of classes atttributes.
Example:
doc_class inv_test1 =
a :: int
doc_class inv_test2 =
b :: "inv_test1"
c:: int
invariant inv_test2 :: "c σ = 1"
invariant inv_test2' :: "a (b σ) = 2"
doc_class inv_test3 = inv_test1 +
b :: "inv_test1"
c:: int
invariant inv_test3 :: "a σ = 1"
invariant inv_test3' :: "a (b σ) = 2"
To support invariant on attributes in attributes
and invariant on attributes of the superclasses,
we check that the type of the attribute of the subclass is ground:›
ML‹
val Type(st, [ty]) = \<^typ>‹inv_test1›
val Type(st', [ty']) = \<^typ>‹'a inv_test1_scheme›
val t = ty = \<^typ>‹unit›
›
- The current implementation triggers a warning when
rejected classes are find in the monitor,
and an error if monitor_strict_checking is enable.
It follows these rules:
Inside the scope of a monitor,
all instances of classes mentioned in its accepts_clause
(the ∗‹accept-set›) have to appear in the order specified
by the regular expression.
Instances not covered by an accept-set may freely occur.
Monitors may additionally contain a rejects_clause
with a list of class-ids (the reject-list).
This allows specifying ranges of
admissible instances along the class hierarchy:
- a superclass in the reject-list and a subclass in the
accept-expression forbids instances superior to the subclass, and
- a subclass S in the reject-list and a superclass T in the
accept-list allows instances of superclasses of T to occur freely,
instances of T to occur in the specified order and forbids
instances of S.
- No message is triggered for the free classes,
but two theory options, free_class_in_monitor_checking
and free_class_in_monitor_strict_checking,
are added and can be used if we want to trigger warnings or errors,
in the case we do not want free classes inside a monitor.
- Fix the checking warning when defining a monitor,
as the monitor was added to the monitor table and then
the instance of the monitor was added to the theory.
So a monitor had the bad behavior to check itself.
By default invariants checking generates warnings.
If invariants_strict_checking theory option is enabled,
the checking generates errors.
- Update 2018-cicm-isabelle_dof-applications/IsaDofApplications.thy
and 2020-iFM-CSP/paper.thy to pass the checking of
the low level invariant checking function "check"
in scholarly_paper.thy,
which checks that the instances in a sequence of the same class
have a growing level.
For a sequence:
section*[intro::introduction]‹ Introduction ›
text*[introtext::introduction, level = "Some 1"]‹...›
introtext must have a level >= than intro.
- Bypass the checking of high-level invariants
when the class default_cid = "text",
the top (default) document class.
We want the class default_cid to stay abstract
and not have the capability to be defined with attribute,
invariants, etc.
Hence this bypass handles docitem without a class associated,
for example when you just want a document element to be referenceable
without using the burden of ontology classes.
ex: text*[sdf]\<open> Lorem ipsum @{thm refl}\<close>
The functions get_doc_class_global and get_doc_class_local trigger
an error when the class is "text" (default_cid),
then the functions like check_invariants which use it will fail
if the checking is enabled by default for all the theories.
Nicolas Méric
Burkhart Wolff
Makarius Wenzel