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.