Type Members

1.  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. x would be represented as Abs("x",typ, Bound(0)) for suitable typ.

   Note that name is for informative purposes only (i.e., it has no logical relevance) since deBrujn indices are used. name can even be "".

2.  final class App extends ConcreteTerm

   A function application (ML constructor $).

   A function application (ML constructor $). fun is the function to be applied and arg its argument. (E.g., t1 $ t2 in ML would have fun=t1 and arg=t2.)

   Can be constructed both as App(t1,t2) or t1 $ t2 in Isabelle. (Pattern matching only supports the syntax App(...), not $.)

3.  final class Bound extends ConcreteTerm

   A bound variable (ML constructor Bound).

   A bound variable (ML constructor Bound). index is the deBrujn index of the variable.

   In a well-formed term, Bound(i) refers to the bound variable from the i-th enclosing Abs. (Starting from 0, i.e., Bound(0) refers to the directly enclosing Abs.)

4.  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, ...).

5.  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).

6.  final class Const extends ConcreteTerm

   A constant (ML constructor Const).

   A constant (ML constructor Const). name is the fully qualified name of the constant (e.g., "HOL.True") and typ its type.

7.  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 by MLValue(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, say countTheorems : Proof.context -> int is an ML function, then we can compile it using

   val 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 is Proof.context and the representation of a context ctxt as an ML exception is E_Context ctxt.

8.  final class Cterm extends Term

   Represents a cterm in Isabelle.

   Represents a cterm in Isabelle. In Isabelle, a cterm must be explicitly converted into a term. 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).

9.  final class Ctyp extends Typ

   Represents a ctyp in Isabelle.

   Represents a ctyp in Isabelle. In Isabelle, a ctyp must be explicitly converted into a typ. 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).

10.  final class Free extends ConcreteTerm

    A free variable (ML constructor Free).

    A free variable (ML constructor Free). name is the name of the variable (e.g., "x") and typ its type.

11.  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 keywords keywords as an ML exception is E_Keywords keywords.

12.  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.

13.  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.

14.  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 mutex m as an ML exception is E_Mutex m.

15.  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 position pos as an ML exception is E_Position pos.

16.  trait PrettyPrintable extends AnyRef

    Base trait for object that can be pretty printed using an Isabelle proof context (Context).

17.  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()

18.  final class TFree extends ConcreteTyp

    A free type variable (ML constructor TFree).

    A free type variable (ML constructor TFree). 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.) Note that type variables whose names do not start with ' are not legal in Isabelle.

19.  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., ?'a is a TVar with name="'a" and index=0. And ?'b1 or ?'b.1 is a TVar with name="'b" and index=1.

    Note that type variables whose names do not start with ' are not legal in Isabelle.

20.  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,u from Isabelle to Scala, and then in Scala construct App(t,u), and then transfer App(t,u) back to Isabelle, the terms t,u will never be serialized, and only the constructor App will 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 form Const (name,typ), then t will match the pattern case 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 is case _ : Const => will not match a term Const(name,typ) represented by an MLValueTerm.

    Two terms are equal (w.r.t.~the equals method) 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 as case Const(name,typ) => also match Cterms.

21.  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 theory thy as an ML exception is E_Theory thy.

22.  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 header header as an ML exception is E_TheoryHeader header.

23.  final class Thm extends FutureValue with PrettyPrintable

    Represents a theorem (ML type thm) in the Isabelle process.

    Represents a theorem (ML type thm) 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.

24.  final class ToplevelState extends MLValueWrapper[ToplevelState]
25.  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,u from Isabelle to Scala, and then in Scala construct Type("fun",List(t,u)), and then transfer Type("fun",List(t,u)) back to Isabelle, the types t,u will never be serialized, and only the constructor Type and 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 form TFree (name,sort), then t will match the pattern case 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 is case _ : TFree => will not match a term TFree(name,sort) represented by an MLValueTyp.

    Two types are equal (w.r.t.~the equals method) 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 as case TFree(name,sort) => also match Ctyps.

26.  final class Type extends ConcreteTyp

    A type constructor (ML constructor Type).

    A type constructor (ML constructor Type). name is the fully qualified name of the type constructor (e.g., "List.list") and args its type parameters.

27.  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., ?x is a Var with name="x" and index=0. And ?y1 or ?y.1 is a Var with name="y" and index=1.

    By convention, schematic variables indicate variables that are can be instantiated/unified.