api

Type Members

1. abstract class Environment extends AnyRef

   

   Abstract interface for an Isabelle environment of a particular version in a path with an underlying PIDE machinery.

   Abstract interface for an Isabelle environment of a particular version in a path with an underlying PIDE machinery.

   As opposed to a mere logic-less Setup, an environment knows how to manage Isabelle processes. It can also manage multiple running processes at the same time.

   A subclass of this class is called implementation througout libisabelle. The Implementations class serves as a registry of those, although using it is not required.

   Users may instantiate implementations manually, although there is a caveat: After one implementation has been instantiated, the behaviour of subsequent instantiations with a different path or instantiations of a different implementation is undefined. For most applications, this is not a significant restriction, because they only deal with a single setup.

   For multi-home or multi-version scenarios, it is highly recommended that users create environments through the appropriate function of a registry. See its documentation for an explanation.

   If in doubt, users should prefer the direct (manual) instantiation.

   While implementations may be created freely by users, it is recommended to only use the bundled implementations for the supported Isabelle versions. By convention, they live in the package edu.tum.cs.isabelle.impl and their class name is also Environment.

   Contract

   • An implementation is a subclass of this class.
   • Implementations must be final and provide a public constructor with exactly one argument (of type java.nio.file.Path).
   • Implementations must be annotated with Implementation, where the given identifier corresponds to the version identifier.

   Footnote

   Due to name clashes in the underlying PIDE machinery (which is provided by Isabelle itself and is not under control of libisabelle), it is impossible to have multiple environments for different versions in the same class loader. This is the primary reason why this class exists in the first place, to enable seamless abstraction over multiple PIDEs.

   As the caveat above states, not even multi-home scenarios are supported without going through a registry. The user has to ensure that this happens, since this class does not attempt to detect such a situation. While in principle it could do so, it would require the introduction of even more global mutable state. It might do so in the future.

2. class Implementation extends Annotation with Annotation with ClassfileAnnotation

   

3. type Markup = (String, Properties)

   

4. type Properties = List[(String, String)]

   

5. trait ProverResult[+T] extends AnyRef

   

   Result from the prover.

   Result from the prover.

   In the error case, a special ProverException will be provided.

   See also

   edu.tum.cs.isabelle.System#invoke

6. case class Version(identifier: String) extends Product with Serializable

   

   Represents the version of an Isabelle release.

   Represents the version of an Isabelle release.

   Repository snapshots are not supported.