Packages

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

Linear Supertypes
Ordering
  1. Alphabetic
  2. By Inheritance
Inherited
  1. pure
  2. AnyRef
  3. Any
  1. Hide All
  2. Show All
Visibility
  1. Public
  2. Protected

Type Members

  1. final class Abs extends ConcreteTerm
  2. final class App extends ConcreteTerm
  3. final class Bound extends ConcreteTerm
  4. sealed abstract class ConcreteTerm extends Term
  5. sealed abstract class ConcreteTyp extends Typ
  6. final class Const extends ConcreteTerm
  7. final class Context extends FutureValue

    Represents a proof context (ML type Proof.context) in the ML context.

    Represents a proof context (ML type Proof.context) in the ML context.

    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.

  8. final class Cterm extends Term
  9. final class Ctyp extends Typ
  10. final class Free extends ConcreteTerm
  11. final class MLValueTerm extends Term
  12. final class MLValueTyp extends Typ
  13. final class TFree extends ConcreteTyp
  14. final class TVar extends ConcreteTyp
  15. sealed abstract class Term extends FutureValue

    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(val name: String, val index: Int, val typ: Typ)  // Corresponds to ML constructor 'Var'
    final case class Abs(val name: String, val typ: Typ, val body: Term)  // Corresponds to ML constructor 'Abs'
    final case class Bound private (val index: Int)                       // Corresponds to ML constructor 'Bound'
    final case class App private (val fun: Term, val 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 processes 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 with additional 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.

  16. final class Theory extends FutureValue

    Represents a proof context (ML type Proof.context) in the ML context.

    Represents a proof context (ML type Proof.context) in the ML context.

    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.

  17. final class Thm extends FutureValue
  18. sealed abstract class Typ extends FutureValue
  19. final class Type extends ConcreteTyp
  20. final class Var extends ConcreteTerm

Value Members

  1. object Abs
  2. object App
  3. object Bound
  4. object Const
  5. object Context extends OperationCollection
  6. object Cterm
  7. object Ctyp
  8. object Free
  9. object Implicits

    Contains all the implicit MLValue.Converter instances provided by the package pure.

    Contains all the implicit MLValue.Converter instances provided by the package pure. Use

    import de.unruh.isabelle.pure.Implicits._

    if you use MLValue[A] instances where A is any of Context, Theory, Term, Typ, Cterm, Ctyp.

  10. object TFree
  11. object TVar
  12. object Term extends OperationCollection
  13. object Theory extends OperationCollection
  14. object Thm extends OperationCollection
  15. object Typ extends OperationCollection
  16. object Type
  17. object Var

Inherited from AnyRef

Inherited from Any

Ungrouped