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.