package pure
This package contains classes for operating on Isabelle theories (Theory), contexts (Context), typs (Typ), term (Term), theorems (Thm). (Only things that are independent of a specific object logic, i.e., only things in Isabelle/Pure.)
- Source
- package.scala
- Alphabetic
- By Inheritance
- pure
- AnyRef
- Any
- Hide All
- Show All
- Public
- All
Type Members
-
final
class
Abs extends ConcreteTerm
A lambda abstraction (ML constructor
Abs).A lambda abstraction (ML constructor
Abs). name is the name of the bound variable, typ is the type of the bound variable, and body is the body of the lambda abstraction.E.g.,
λx. xwould be represented asAbs("x",typ, Bound(0))for suitabletyp.Note that name is for informative purposes only (i.e., it has no logical relevance) since deBrujn indices are used. name can even be
"". -
final
class
App extends ConcreteTerm
A function application (ML constructor
$). -
final
class
Bound extends ConcreteTerm
A bound variable (ML constructor
Bound). -
sealed abstract
class
ConcreteTerm extends Term
Base class for all concrete terms.
Base class for all concrete terms. A ConcreteTerm guarantees that the type of the term (App,Const,Abs...) corresponds to the top-level constructor on Isabelle side (
$,Const,Abs, ...). -
sealed abstract
class
ConcreteTyp extends Typ
Base class for all concrete types.
Base class for all concrete types. A ConcreteTyp guarantees that the Scala-type of the Typ (Type,TFree,TVar...) corresponds to the top-level constructor on Isabelle side (
Type,TFree,TVar). -
final
class
Const extends ConcreteTerm
A constant (ML constructor
Const). -
final
class
Context extends MLValueWrapper[Context]
Represents a proof context (ML type
Proof.context) in the Isabelle process.Represents a proof context (ML type
Proof.context) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, that is, the context is never transferred to the Scala process (which would not be possible because a context cannot be serialized). However, by having this wrapper, a context can be treated as if it were a Scala object (as opposed to a value stored in the Isabelle process).
This class is compatible with the MLValue mechanism. That is, from a Context
context, we can create an MLValueContext byMLValue(context), and we can get a Context back using.retrieve/.retrieveNow. This conversion is needed if we want to pass contexts to (or return contexts from) ML functions compiled using MLValue.compileFunction. For example, saycountTheorems : Proof.context -> intis an ML function, then we can compile it usingval countTheorems = MLValue.compileFunction[Context,Int]("countTheorems")
and invoke it as
val num : Int = countTheorems(context).retrieveNow // where context : Context
Make sure to import de.unruh.isabelle.pure.Implicits
._for the MLValue-related functions to work.Not that contexts (being MLValues), are internally futures and may still fail. To make sure a Context actually contains a value, use, e.g., Context.force.
An implict MLValue.Converter can be imported from Implicits
._. The ML type isProof.contextand the representation of a contextctxtas an ML exception isE_Context ctxt. -
final
class
Cterm extends Term
Represents a
ctermin Isabelle.Represents a
ctermin Isabelle. In Isabelle, actermmust be explicitly converted into aterm. In contrast, this class inherits from Term, so no explicit conversions are needed. (They happen automatically on demand.) A Cterm is always well-typed relative to the context for which it was created (this is ensured by the Isabelle trusted core). -
final
class
Ctyp extends Typ
Represents a
ctypin Isabelle.Represents a
ctypin Isabelle. In Isabelle, actypmust be explicitly converted into atyp. In contrast, this class inherits from Typ, so no explicit conversions are needed. (They happen automatically on demand.) A Ctyp is always well-formed relative to the context for which it was created (this is ensured by the Isabelle trusted core). -
final
class
Free extends ConcreteTerm
A free variable (ML constructor
Free). -
final
class
Keywords extends MLValueWrapper[Keywords]
Represents a specification of Isar keywords as given in a theory header (ML type
Thy_Header.keywords) in the Isabelle process.Represents a specification of Isar keywords as given in a theory header (ML type
Thy_Header.keywords) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
An implict MLValue.Converter can be imported from Implicits
._. The representation of keywordskeywordsas an ML exception isE_Keywords keywords. -
final
class
MLValueTerm extends Term
A Term that is stored in the Isabelle process's object store and may or may not be known in Scala.
A Term that is stored in the Isabelle process's object store and may or may not be known in Scala. Use concrete to get a representation of the same term as a ConcreteTerm.
-
final
class
MLValueTyp extends Typ
A Typ that is stored in the Isabelle process's object store and may or may not be known in Scala.
A Typ that is stored in the Isabelle process's object store and may or may not be known in Scala. Use concrete to get a representation of the same type as a ConcreteTyp.
-
final
class
Mutex extends MLValueWrapper[Mutex]
Represents a mutex (ML type
Mutex.mutex) in the Isabelle process.Represents a mutex (ML type
Mutex.mutex) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
An implict MLValue.Converter can be imported from Implicits
._. The representation of a mutexmas an ML exception isE_Mutex m. -
final
class
Position extends MLValueWrapper[Position]
Represents a position (ML type
Position.T) in the Isabelle process.Represents a position (ML type
Position.T) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
An implict MLValue.Converter can be imported from Implicits
._. The representation of a positionposas an ML exception isE_Position pos. -
trait
PrettyPrintable extends AnyRef
Base trait for object that can be pretty printed using an Isabelle proof context (Context).
-
sealed
trait
Proofterm extends AnyRef
Support for Isabelle proofterms.
Support for Isabelle proofterms. Experimental and incomplete. May throw NotImplementedError and change without notice. Not documented.
- Annotations
- @Experimental()
-
final
class
TFree extends ConcreteTyp
A free type variable (ML constructor
TFree). -
final
class
TVar extends ConcreteTyp
A schematic type variable (ML constructor
TVar).A schematic type variable (ML constructor
TVar). name is the name of the type variable (e.g.,"'a'") and sort its sort. (The sort is a list of fully qualified type class names.)Schematic type variables are the ones that are represented with a leading question mark in Isabelle's parsing and pretty printing. E.g.,
?'ais a TVar with name="'a"and index=0. And?'b1or?'b.1is a TVar with name="'b"and index=1.Note that type variables whose names do not start with ' are not legal in Isabelle.
-
sealed abstract
class
Term extends FutureValue with PrettyPrintable
This class represents a term (ML type
term) in Isabelle.This class represents a term (ML type
term) in Isabelle. It can be transferred to and from the Isabelle process transparently by internally using MLValues (see below).In most respects, Term behaves as if it was an algebraic datatype defined as follows:
sealed abstract class Term final case class Const(name: String, typ: Typ) // Corresponds to ML constructor 'Const' final case class Free(name: String, typ: Typ) // Corresponds to ML constructor 'Free' final case class Var(name: String, index: Int, typ: Typ) // Corresponds to ML constructor 'Var' final case class Abs(name: String, typ: Typ, body: Term) // Corresponds to ML constructor 'Abs' final case class Bound private (index: Int) // Corresponds to ML constructor 'Bound' final case class App private (fun: Term, arg: Term) // Corresponds to ML constructor '$'
tl;dr for the explanation below: Terms can be treated as if they were the case classes above (even though there actually are more classes), both in object creation and in pattern matching, with the exception that one should not use type patterns (e.g.,
case _ : Const =>).Having Terms defined in terms of those case classes would mean that when retrieving a term from the Isabelle process, the whole term needs to be retrieved. Since terms can be very large and might be transferred back and forth a lot (with minor modifications), we choose an approach where terms may be partially stored in Scala, and partially in the Isabelle process. That is, an instance of Term can be any of the above classes, or a reference to a term in the object store in the Isabelle process, or both at the same time. And the same applies to subterms, too. So for example, if we retrieve terms
t,ufrom Isabelle to Scala, and then in Scala constructApp(t,u), and then transferApp(t,u)back to Isabelle, the termst,uwill never be serialized, and only the constructorAppwill need to be transferred.In order to faciliate this, the classes Const, Free, Var, Abs, Bound, App (collectively referred to as a ConcreteTerm) additionally store an reference Term.mlValue to the Isabelle object store (this reference is initialized lazily, thus accessing it can force the term to be transferred to the Isabelle process). And furthermore, there is an additional subclass MLValueTerm of Term that represents a term that is stored in Isabelle but not available in Scala at class creation time. Instances of MLValueTerm never need to be created manually, though. You just have to be aware that some terms might not be instances of the six ConcreteTerm "case classes". (But if a ConcreteTerm is required, any term can be converted using
term.concrete.)Pattern matching works as expected, that is, when an MLValueTerm
t, e.g., refers to an Isabelle term of the formConst (name,typ), thentwill match the patterncase Const(name,typ) =>. (Necessary information will be transferred from the Isabelle process on demand.) Because of this, one can almost completely ignore the existence of MLValueTerm. The only caveat is that one should not do a pattern match on the type of the term. That iscase _ : Const =>will not match a termConst(name,typ)represented by an MLValueTerm.Two terms are equal (w.r.t.~the
equalsmethod) iff they represent the same Isabelle terms. I.e., an MLValueTerm and a Const can be equal. (Equality tests try to transfer as little data as possible when determining equality.)Furthermore, there is a subclass Cterm of Term that represents an ML value of type
cterm. This is logically a term that is certified to be well-typed with respect to some Isabelle context. In this implementation, a Cterm is also a Term, so it is possible to do, e.g., equality tests between Cterms and regular terms (such as Const) without explicit conversions. Similarly, patterns such ascase Const(name,typ) =>also match Cterms. -
final
class
Theory extends FutureValue
Represents a theory (ML type
theory) in the Isabelle process.Represents a theory (ML type
theory) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
The name of the theory can be retrieved via the member name if the theory was created by Theory
(name). Otherwise, name returns a placeholder.An implict MLValue.Converter can be imported from Implicits
._. The representation of a theorythyas an ML exception isE_Theory thy. -
final
class
TheoryHeader extends MLValueWrapper[TheoryHeader]
Represents a theory header (ML type
Thy_Header.header) in the Isabelle process.Represents a theory header (ML type
Thy_Header.header) in the Isabelle process.An instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
An implict MLValue.Converter can be imported from Implicits
._. The representation of a headerheaderas an ML exception isE_TheoryHeader header. -
final
class
Thm extends FutureValue with PrettyPrintable
Represents a theorem (ML type
thm) in the Isabelle process. -
final
class
ToplevelState extends MLValueWrapper[ToplevelState]
Represents a toplevel state (the state when processing an Isar .thy document).
Represents a toplevel state (the state when processing an Isar .thy document). ML type:
Toplevel.stateAn instance of this class is merely a thin wrapper around an MLValue, all explanations and examples given for Context also apply here.
An implict MLValue.Converter can be imported from Implicits
._. The representation of a toplevel statestateas an ML exception isE_ToplevelState state. -
sealed abstract
class
Typ extends FutureValue with PrettyPrintable
This class represents a typ (ML type
typ) in Isabelle.This class represents a typ (ML type
typ) in Isabelle. It can be transferred to and from the Isabelle process transparently by internally using MLValues (see below).In most respects, Typ behaves as if it was an algebraic datatype defined as follows:
sealed abstract class Typ final case class Type(name: String, args: List[Typ]) // Corresponds to ML constructor 'Type' final case class TFree(name: String, sort: List[String]) // Corresponds to ML constructor 'TFree' final case class TVar(name: String, index: Int, sort: List[String]) // Corresponds to ML constructor 'TVar'
tl;dr for the explanation below: Types can be treated as if they were the case classes above (even though there actually are more classes), both in object creation and in pattern matching, with the exception that one should not use type patterns (e.g.,
case _ : Const =>).Having Typs defined in terms of those case classes would mean that when retrieving a type from the Isabelle process, the whole type needs to be retrieved. Since types can be large and might be transferred back and forth a lot (with minor modifications), we choose an approach where types may be partially stored in Scala, and partially in the Isabelle process. That is, an instance of Typ can be any of the above classes, or a reference to a type in the object store in the Isabelle process, or both at the same time. And the same applies to subterms of the type, too. So for example, if we retrieve types
t,ufrom Isabelle to Scala, and then in Scala constructType("fun",List(t,u)), and then transferType("fun",List(t,u))back to Isabelle, the typest,uwill never be serialized, and only the constructorTypeand the string"fun"will need to be transferred.In order to faciliate this, the classes Type, TFree, TVar (collectively referred to as a ConcreteTyp) additionally store an reference Typ.mlValue to the Isabelle object store (this reference is initialized lazily, thus accessing it can force the type to be transferred to the Isabelle process). And furthermore, there is an additional subclass MLValueTyp of Typ that represents a type that is stored in Isabelle but not available in Scala at class creation time. Instances of MLValueTyp never need to be created manually, though. You just have to be aware that some types might not be instances of the three ConcreteTyp "case classes". (But if a ConcreteTyp is required, any term can be converted using
typ.concrete.)Pattern matching works as expected, that is, when an MLValueTyp
t, e.g., refers to an Isabelle type of the formTFree (name,sort), thentwill match the patterncase TFree(name,sort) =>. (Necessary information will be transferred from the Isabelle process on demand.) Because of this, one can almost completely ignore the existence of MLValueTyp. The only caveat is that one should not do a pattern match on the Scala-type of the Typ. That iscase _ : TFree =>will not match a termTFree(name,sort)represented by an MLValueTyp.Two types are equal (w.r.t.~the
equalsmethod) iff they represent the same Isabelle types. I.e., an MLValueTyp and a TFree can be equal. (Equality tests try to transfer as little data as possible when determining equality.)Furthermore, there is a subclass Ctyp of Typ that represents an ML value of type
ctyp. This is logically a type with additional that is certified to be well-formed with respect to some Isabelle context. In this implementation, a Ctyp is also a Typ, so it is possible to do, e.g., equality tests between Ctyps and regular terms (such as TFree) without explicit conversions. Similarly, patterns such ascase TFree(name,sort) =>also match Ctyps. -
final
class
Type extends ConcreteTyp
A type constructor (ML constructor
Type). -
final
class
Var extends ConcreteTerm
A schematic variable (ML constructor
Var).A schematic variable (ML constructor
Var). name is the name of the variable (e.g.,"x"), index its index, and typ its type.Schematic variables are the ones that are represented with a leading question mark in Isabelle's parsing and pretty printing. E.g.,
?xis a Var with name="x"and index=0. And?y1or?y.1is a Var with name="y"and index=1.By convention, schematic variables indicate variables that are can be instantiated/unified.
Value Members
- object Abs
- object App
- object Bound
- object Const
- object Context extends Companion[Context]
- object Cterm
- object Ctyp
- object Free
-
object
Implicits
Contains all the implicit MLValue.Converter instances provided by the package pure.
- object Keywords extends Companion[Keywords]
- object Mutex extends Companion[Mutex]
- object PathConverter extends Converter[Path] with OperationCollection
- object Position extends Companion[Position]
-
object
Proofterm extends OperationCollection
Support for Isabelle proofterms.
Support for Isabelle proofterms. Experimental and incomplete. May throw NotImplementedError and change without notice. Not documented.
- Annotations
- @Experimental()
-
object
StringInterpolators extends OperationCollection
Provides string interpolators for conveniently creating Isabelle terms and types.
Provides string interpolators for conveniently creating Isabelle terms and types.
It allows us to write, e.g.,
term"x+y"to parse the termx+y. Ortyp"nat"to parse the typenatIn addition, subterms of terms can refer to already existing Term objects, e.g.,
term"x+$term"for a Scala variabletermof type Term.We can also refer to existing Typ objects, both in terms and types. E.g.,
term"x :: $typortyp"$typ => $typ"for a Scala variable of type Typ.The support for the interpolators is activated by importing the implicits
import de.unruh.isabelle.pure.Implicits._.To use the interpolators, an implicit Isabelle instance, an implicit ExecutionContext, and an implicit Context must be given. (The latter provides the theory context in which to parse the terms/types.)
Parsing happens at runtime, there is no compile-time validation of the terms/types.
An example how to use type and term interpolators:
import de.unruh.isabelle.pure.Implicits._ import scala.concurrent.ExecutionContext.Implicits.global implicit isabelle = new Isabelle(...) implicit context = Context("Main") // Parsing w.r.t. Isabelle theory Main val typ1 = typ"nat" // type nat val typ2 = typ"$typ1 => $typ1" // type nat => nat val term1 = term"f :: $typ2" // term f :: nat => nat val term2 = term"$term1 1" // term (f :: nat => nat) (1 :: nat) (by type inference)
The interpolators can also be used for pattern matching. That is,
term"..."andtyp"..."can appear in the pattern in a Scala pattern match. Example:// implicits as above val term = term"1 + (2::nat)" term match { case term"$t + (_::$u::plus)" => (t,u) // t : Term is "1::nat", u : Typ is "nat" } val typ = typ"nat => nat" typ match { case typ"$t => $dummy" => t // t : Typ is "nat" }
(Note: A subtlety is that we write
$u::plusinstad of just$uin the pattern above. This is because Isabelle otherwise refuses to parse the term: a schematic type variable (into which$uis converted for parsing purposes) needs to be annotated with a sort that makes the overall term well-typed.)(Note: Another subtlety is that we use
$dummyinstead of_to indicate a wildcard intyp"$t => $dummy". This is because Isabelle does not support_in pattern matches for types. We could also write$_instead of$dummyhere because then_is a Scala-wildcard, not an Isabelle wildcard.)Invalid (i.e., unparseable) strings raise an IsabelleException. This also applied if
...in patternsterm"..."ortyp"..."cannot be parsed. - object TFree
- object TVar
- object Term extends OperationCollection
- object Theory extends OperationCollection
- object TheoryHeader extends Companion[TheoryHeader]
- object Thm extends OperationCollection
- object ToplevelState extends Companion[ToplevelState]
- object Typ extends OperationCollection
- object Type
- object Var