Environment
Related Docs:
object Environment
| package api
Represents the location and name of a session (Isabelle terminology).
Represents the location and name of a session (Isabelle terminology).
Refer to the Isabelle system manual for details about sessions.
libisabelle assumes that users are familiar with the session handling
of Isabelle.
Creation of configurations is completely unchecked. Errors such as non-existing paths will only manifest themselves when attempting to build a configuration or create a system. Nonetheless, users should go through one of the constructors in the companion object.
An iteratee-like structure consuming XML trees and eventually
producing an output of type T, or an error.
An iteratee-like structure consuming XML trees and eventually
producing an output of type T, or an error.
On a high level, this can be imagined like a function taking a list of
trees as an argument. In most cases, user code does not care about the
intermediate results. For that, combinators exist in the
companion object and
Operation.
The execution context internally used by the underlying PIDE implementation.
The execution context internally used by the underlying PIDE implementation.
It is allowed to override the execution context of internal PIDE implementation during initialization, but it must remain fixed afterwards. This field must be set to that execution context.
Implementations should ensure that the underlying thread pool consists of daemon threads, rendering disposing of running systems unnecessary. (The secondary reason is to avoid a hanging JVM when user code did not handle an exception, the main thread gets terminated, but worker threads are keeping the JVM alive.)
This is exposed to the user via
System#executionContext.
Convenience constructors for configurations.
Cases of observers and combinators.
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. TheImplementationsclass 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.impland their class name is alsoEnvironment.Contract
java.nio.file.Path).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.