I know that the typedecl and consts commands can be used in Isabelle (as of 2021) to declare a new type/constant without defining it. For example:
typedecl state
consts M :: "(state × state)set"
typedecl "atom"
consts L :: "state ⇒ atom set"
My questions are:
Can one define the type/constants to be some actual type or constants after the declaration?
If so, can multiple definitions be defined in different theories to implement those declarations? (, so that the declaration serves as an interface)
I have seen some old documents that use defs (plus consts) command to define things, but it no longer seems to be defined in Isabelle 2021.
Related
What is the correct way in Isabelle/HOL (2021) to define a function f from a specific set A to another set B?
From mathematics, a function f: A -> B is often defined as a map from its domain A to its co-domain B. And a function f is defined as a special kind of relation in A × B with only one y ∈ B that satisfies x f y for each x ∈ A.
But in Isabelle/HOL, functions seems to be defined in terms of computation, e.g. f x = Suc x. It seems that there is no place to define domain and co-domains explicitly.
I was just wondering if there is a conventional way to define functions in Isabelle to be with domain and co-domains and be compatible with the definition of relations above.
Background
As you have noted, in Isabelle/HOL, conventionally, a function is a term of the type 'a⇒'b, where 'a and 'b can be arbitrary types. As such, all functions in Isabelle are total. There is a blog post by Joachim Breitner that explains this very well: link. I will not restate any elements of the content of the blog post: instead, I will concentrate on the issue that you have raised in your question.
Conventional definitions of a function
I am aware of two methodologies for the definition of a function in traditional mathematics (here I use the term "traditional mathematics" to mean mathematics exposed in some set-theoretic foundation):
According, for example, to [1,Chapter 6], a function is simply a single-valued binary relation.
Some authors [2,Chapter 2] identify a function with its domain and codomain by definition, i.e. a function becomes a triple (A,B,r), where r⊆A×B is still a single-valued binary relation and A is exactly the domain of the relation.
You can find some further discussion here. If the function is a binary relation, then the domain and the range are normally identified with the domain and the range of the relation that the function represents. However, it makes little sense to speak about the codomain of such an entity. If the function is defined as a triple (A,B,r), then the codomain is the assigned set B.
Isabelle/HOL I: functions as relations
Isabelle/HOL already provides a definition of the concept of a single-valued relation in the theory Relation.thy. The definition is implicit in the definition of the predicate single_valued:
definition single_valued :: "('a × 'b) set ⇒ bool"
where "single_valued r ⟷ (∀x y. (x, y) ∈ r ⟶ (∀z. (x, z) ∈ r ⟶ y = z))"
Thus, effectively, a single-valued relation is a term of the type ('a × 'b) set such that it satisfies the predicate single_valued. Some elementary results about this definition are also provided.
Of course, this predicate can be used to create a new type constructor of "functions-as-relations" from 'a to 'b. See the official documentation of Isabelle [3, section 11.7] and the article Lifting and Transfer: A Modular Design for Quotients in Isabelle/HOL [4, section 3] for further information about defining new type constructors in Isabelle/HOL. It is not unlikely that such a type is already available somewhere, but I could not find it (or anything similar) after a quick search of the sources.
Of course, there is little that can prevent one from providing a type that captures either of the set-theoretic definitions of a function presented in the previous subsection of the answer. I guess, something like the following definition could work, but I have not tested it:
typedef ('a, 'b) relfun =
‹
{
(A::'a set, B::'b set, f::('a × 'b) set).
single_valued f ∧ Domain f = A ∧ Range f ⊆ B
}
›
proof-
let ?r = ‹({}, {}, {})›
show ?thesis unfolding single_valued_def by (intro exI[of _ ?r]) simp
qed
Isabelle/HOL II: FuncSet and other restrictions
While the functions in Isabelle/HOL are total, one can still mimick the restriction of a function to a certain pre-defined domain (i.e. a proper subset of UNIV::'a set) using a variety of methodologies. One common methodology (exposed in the theory HOL-Library.FuncSet) is to force the function to be undefined on parts of the domain. My answer in the following thread explains this in more detail.
Isabelle/HOL III: HOL/ZF, ZFC in HOL and HOTG
This might be marginally off-topic. However, there exist extensions of Isabelle/HOL with the axioms of set-theory of different strengths [5,6,7]. For example, ZFC in HOL [6] provides a certain type V that represents the von Neumann universe. One can now define all relevant set-theoretic concepts internalized in this type, including, of course, either one of the conventional definitions of a function. In ZFC in HOL one can internalize functions defined in HOL using the so-called operator VLambda like so: (F::V) = VLambda (A::V) (f::V⇒V). Now, F is a single-valued binary relation internalized in the type V with the domain A and the values of the form ⟨x, f x⟩.
As a side note, I have exposed both definitions of a function as predicates on V explicitly while working on my own formalization of category theory: Category Theory for ZFC in HOL.
Summary
What is the correct way in Isabelle/HOL (2021) to define a function f
from a specific set A to another set B?
To answer your question directly, my opinion is that there is no single "correct way" to define a function from a specific set A to another set B. However, you have many options that you can explore: each of these options will have advantages and disadvantages that are specific to it.
References
Takeuti G, Zaring WM. Introduction to Axiomatic Set Theory. Heidelberg: Springer-Verlag; 1971.
Goldblatt R. Topoi: The Categorial Analysis of Logic. Mineola: Dover Publications; 2013.
Wenzel M. The Isabelle/Isar Reference Manual. 2019.
Huffman B, Kunčar O. Lifting and Transfer: A Modular Design for Quotients in Isabelle/HOL. In: Gonthier G, Norrish M, editors. Certified Programs and Proofs. Heidelberg: Springer; 2013. p. 131–46.
Obua S. Partizan Games in Isabelle/HOLZF. In: Barkaoui K, Cavalcanti A, Cerone A, editors. Theoretical Aspects of Computing - ICTAC 2006. Berlin: Springer; 2006. p. 272–86.
Paulson LC. Zermelo Fraenkel Set Theory in Higher-Order Logic. Archive of Formal Proofs. 2019.
Chen J, Kappelmann K, Krauss A. https://bitbucket.org/cezaryka/tyset/src [Internet]. HOTG. Available from: https://bitbucket.org/cezaryka/tyset/src.
The Isabelle reference manual describes to ways to perform type-based overloading of constants: "Adhoc overloading of constants" in section 11.3, and "Overloaded constant definitions" in section 5.9.
It seems that 5.9 overloading requires all type parameters to be known before it decides on an overloaded constant, whereas 11.3 (adhoc) overloading decides on an overloaded constant if there is only one matching:
consts
c1 :: "'t ⇒ 'a set"
c2 :: "'t ⇒ 'a set"
definition f1 :: ‹'a list ⇒ 'a set› where
‹f1 s ≡ set s›
adhoc_overloading
c1 f1
overloading
f2 ≡ ‹c2 :: 'a list ⇒ 'a set›
begin
definition ‹f2 w ≡ set w›
end
context
fixes s :: ‹int list›
begin
term ‹c1 s› (* c1 s :: int set *)
term ‹c2 s› (* c2 s :: 'a set *)
end
What's the difference between the two? When would I use one over the other?
Overloading is a core feature of Isabelle's logic. It allows you to declare a single constant with a "broad" type that can be defined on specific types. There's rarely a need for users to do that manually. It is the underlying mechanism used to implement type classes. For example, if you define a type class as follows:
class empty =
fixes empty :: 'a
assumes (* ... *)
Then, the class command will declare the constant empty of type 'a', and subsequent instantiations merely provide a definition of empty for specific types, like nat or list.
Long story short: overloading is – for most purposes – an implementation detail that is managed by higher-level commands. Occasionally, the need for some manual tweaking arises, e.g. when you have to define a type that depends on class constraints.
Ad-hoc overloading is, in my opinion, a misleading name. As far as I understand, it stems from Haskell (see this paper from Wadler and Blott). There, they use it to describe precisely the type class mechanism that in Isabelle would be coined as just "overloading". In Isabelle, ad-hoc overloading means something entirely different. The idea is that you can use it to define abstract syntax (like do-notation for monads) that can't accurately be capture by Isabelle's ML-style simple type system. As in overloading, you'd define a constant with a "broad" type. But that constant never receives any definitions! Instead, you define new constants with more specific types. When Isabelle's term parser encounters the use of the abstract constant, it will try to replace it with a concrete constant.
For example: you can use do-notation with option, list, and a few other types. If you write something like:
do { x <- foo; bar }
Then Isabelle sees:
Monad_Syntax.bind foo (%x. bar)
In a second step, depending on the type of foo, it will translate it to one of these possible terms:
Option.bind foo (%x. bar)
List.bind foo (%x. bar)
(* ... more possibilities ...*)
Again, users probably don't need to deal with this concept explicitly. If you pull in Monad_Syntax from the library, you'll get one application of ad-hoc overloading readily configured.
Long story short: ad-hoc overloading is a mechanism for enabling "fancy" syntax in Isabelle. Newbies may get confused by it because error messages tend to be hard to understand if there's something wrong in the internal translation.
The following code doesn't typecheck:
type_synonym env = "char list ⇀ val"
interpretation map: order "op ⊆⇩m :: (env ⇒ env ⇒ bool)" "(λa b. a ≠ b ∧ a ⊆⇩m b)"
by unfold_locales (auto intro: map_le_trans simp: map_le_antisym)
lemma
assumes "mono (f :: env ⇒ env)"
shows "True"
by simp
Isabelle complains with the following error at the lemma:
Type unification failed: No type arity option :: order
Type error in application: incompatible operand type
Operator: mono :: (??'a ⇒ ??'b) ⇒ bool
Operand: f :: (char list ⇒ val option) ⇒ char list ⇒ val option
Why so? Did I miss something to use the interpretation? I suspect I need something like a newtype wrapper here...
When you interpret a locale like order which corresponds to a type class, you only get the theorems proved inside the context of the locale. However, the constant mono is only defined on the type class. The reason is that mono's type contains two type variables, whereas only one is available inside locales from type classes. You can notice this because there is no map.mono stemming from your interpretation.
If you instantiate the type class order for the option type with None being less than Some x, then you can use mono for maps, because the function space instantiates order with the pointwise order. However, the ordering <= on maps will only be semantically equivalent to ⊆⇩m, not syntactically, so none of the existing theorems about ⊆⇩m will work for <= and vice versa. Moreover, your theories will be incompatible with other people's that instantiate order for option differently.
Therefore, I recommend to go without type classes. The predicate monotone explicitly takes the order to be used. This is a bit more writing, but in the end, you are more flexible than with type classes. For example, you can write monotone (op ⊆⇩m) (op ⊆⇩m) f to express that f is a monotone transformation of environments.
I wanted to define the class of topological vector spaces in the obvious way:
theory foo
imports Real_Vector_Spaces
begin
class topological_vector = topological_space + real_vector +
assumes add_cont_fst: "∀a. continuous_on UNIV (λb. a + b)"
...
but I got the error Type inference imposes additional sort constraint topological_space of type parameter 'a of sort type
I tried introducing type constraints in the condition, and it looks like
continuous_on doesn't want to match with the default type 'a of the class.
Of course I can work around this by replacing continuity with equivalent conditions, I'm just curious why this doesn't work.
Inside a class definition in Isabelle/HOL, there may occur only one type variable (namely 'a), which has the default HOL sort type. Thus, one cannot formalise multi-parameter type classes. This also affects definitions inside type classes, which may depend only on the parameters of one type class. For example, you can define a predicate cont :: 'a set => ('a => 'a) => bool inside the type class context topological_space as follows
definition (in topological_space) cont :: "'a set ⇒ ('a ⇒ 'a) ⇒ bool"
where "cont s f = (∀x∈s. (f ---> f x) (at x within s))"
The target (in topological_space) tells the type class system that cont really depends only on one type. Thus, it is safe to use cont in assumptions of other type classes which inherit from topological_space.
Now, the predicate continuous_on in Isabelle/HOL has the type 'a set => ('a => 'b) => bool where both 'a and 'b must be of sort topological_space. Thus, continuous_on is more general than cont, because it allows different topological spaces a and b. Conversely, continuous_on cannot be defined within any one type class. Consequently, you cannot use continuous_on in assumptions of type classes either. This restriction is not specific to continuous_on, it appears for all kinds of morphisms, e.g. mono for order-preserving functions, homomorphisms between algebraic structures, etc. Single-parameter type classes just cannot express such things.
In your example, you get the error because Isabelle unifies all occuring type variables to 'a and then realises that continuous_on forces the sort topological_space on 'a, but for the above reasons, you may not depend on sorts in class specifications.
Nevertheless, there might be a simple way out. Just define cont as described above and use it in the assumptions of topological_vector instead of continuous_on. Outside of the class context, you can then prove that cont = continuous_on and derive the original assumption with continuous_on instead of cont. This keeps you from reasoning abstractly within the class context, but this is only a minor restriction.
In Isabelle, is there a way to ensure that instantiations for two type variables in a locale or proposition are different?
For a concrete example, I want to reason about a composite entity without committing to a specific representation. To this end I define a class of components, with some operations on them:
class Component = fixes oper :: "'a ⇒ 'a"
I also define a Composite, which has the same operations, lifted by applying them component-wise plus selectors for the components:
class Composite = Component (* + ... *)
locale ComponentAccess =
fixes set :: "'c :: Composite ⇒ 'a :: Component ⇒ 'c"
and get :: "'c ⇒ 'a"
assumes (* e.g. *) "get (set c a) = a"
and "set c (get c) = c"
and "oper (set c1 a1) = set (oper c1) (oper a2)"
Now I want to state some axioms for a pairwise composite, e.g.:
locale CompositeAxioms =
a: ComponentAccess set get + b: ComponentAccess set' get'
for set :: "'c :: Composite ⇒ 'a1 :: Component ⇒ 'c"
and get :: "'c ⇒ 'a1"
and set' :: "'c ⇒ 'a2 :: Component ⇒ 'c"
and get' :: "'c ⇒ 'a2" +
assumes set_disj_commut: "set' (set c a1) a2 = set (set' c a2) a1"
However, the above law is only sensible if 'a1 and 'a2 are instantiated to different types. Otherwise we trivially get unwanted consequences, like reverting a component setting:
lemma
fixes set get
assumes "CompositeAxioms set get set get"
shows "set (set c a1) a2 = set (set c a2) a1"
using assms CompositeAxioms.set_disj_commut by blast
In the above locale and it's assumes, is there a way of ensuring that 'a1 and 'a2 are always instantiated to different types?
Update (clarification). Actually, the 'law' makes sense only if set and set' are different. But then I would have to compare two functions over different types which, I think, is not possible. Since I define get/set operations in type classes and use sort constraints to ensure that a composite has certain components, my gets and sets always differ in the component type. Hence the question.
You can express in Isabelle/HOL that two types are different by using the reflection of types as terms. To that end, the types must be representable, i.e., instantiate the class typerep. Most types in HOL do so. Then, you can write
TYPEREP('a) ~= TYPEREP('b)
to express that 'a and 'b can only be instantiated to different types. However, TYPEREP is normally used only for internal purposes (especially in the code generator), so there is no reasoning infrastructure available and I do not know how to exploit such an assumption.
Anyway, I wonder why you want to formulate such a constraint at all. If a user instantiates your locale CompositeAxioms with both components being the same (and leave the swapping law for set and set' as is), it is the user who has to show the swapping law. If he can, then the set function is a bit strange, but soundness is not affected. Moreover, a locale assumption like TYPEREP('a) ~= TYPEREP('b) would unnecessarily restrict the generality of your development, is it might be perfectly sensible to use the same representation type with different instances for set and get.