| Quellcodebibliothek Statistik Leitseite products/Sources/formale Sprachen/Isabelle/Doc/System/ (Beweissystem Isabelle Version 2025-1©) Datei vom 16.11.2025 mit Größe 21 kB |
|
Quelle Scala.thySprache: Isabelle |
|||||||||||||||
|
(*:maxLineLen=78:*) theory Scala imports Base begin chapter < \ text ‹ Isabelle/ML and Isabelle/Scala are the two main implementation langua the Isabelle environment: ▪ Isabelle/ML is for 🪙‹mathematics›, to develop tools within the context of symbolic logic, e.g.\ for constructing proofs or defining domain-specific formal languages. See the 🪙‹Isabelle/Isar implementation manual› cite‹"isabelle-implementation"› for more details. ▪ Isabelle/Scala is for 🪙‹physics›, to connect with the world of systems and services, including editors and IDE frameworks. There are various ways to access Isabelle/Scala modules and operations: ▪ Isabelle command-line tools (\secref{sec:scala-tools}) run in a separate Java process. ▪ Isabelle/ML antiquotations access Isabelle/Scala functions (\secref{sec:scala-functions}) via the PIDE protocol: execution happens within the running Java process underlying Isabelle/Scala. ▪ The 🍋‹Console/Scala› plugin of Isabelle/jEdit cite‹"isabelle-jedit"› operates on the running Java application, using the Scala read-eval-print-loop (REPL). The main Isabelle/Scala/jEdit functionality is provided by 🍋‹$ISABELLE_HOME/lib/classes/isabelle.jar›. Further underlying Scala and Java libraries are bundled with Isabelle, e.g.\ to access SQLite or PostgreSQL via JDBC. Add-on Isabelle components may augment the system environment by providing suitable configuration in 🍋‹etc/settings› (GNU bash script). The shell function 🪙‹classpath› helps to write 🍋‹etc/settings› in a portable manner: it refers to library 🍋 ana files in standard POSIX path notation. On Windows, this is converted to native platform format, before invoking Java (\secref{sec:scala-tools}). 🪙 There is also an implicit build process for Isabelle/Scala/Java modules, based on 🍋 \secref{sec:scala-build}). See 🍋‹$ISABELLE_HOME/src/Tools/Demo/README.md› for an example components with command-line tools in Isabelle/Scala. › section ‹ ‹ ‹ The @{tool_def java} tool is a direct wrapper for the Java Runtime Environment, within the regular Isabelle settings environment (\secref{sec:settings}) and Isabelle classpath. The command line arguments are that of the bundled Java distribution: see option 🍋› particular. The 🍋‹java› executable is taken from @{setting ISABELLE_JDK_HOME}, according to the standard directory layout for regular distributions of OpenJDK. The shell function 🪙 & & 🚫\\ invoke other Java tools robustly (e.g.\ 🍋‹isabelle_jdk jar›), without depending on accidental operating system installations. › ‹Scala toplevel \label{sec:tool-scala}› ‹ The @{tool_def scala} tool is a direct wrapper for the Scala toplevel, similar to @{tool java} above. The command line arguments are that of the bundled Scala distribution: see option 🍋‹-help› to interact with Isabelle/Scala interactively. › ‹ ‹rail>\>‹ Explore the Isabelle system environment in Scala: @{verbatim [display, indent = 2] ‹ @{scala [display, indent = 2] ‹import isabelle._ isabelle_home = Isabelle_System.getenv("ISABELLE_HOME") options = Options.init() .bool("browser_info") .string("document")›} › ‹ ‹ The @{tool_def scalac} tool is a direc d wrapper fo the Scalcom; see also @{tool scala} above. The command line arguments are that of the bundled Scala distribution. This provides a low-level mechanism to compile further Scala modules, depending on existing Isabelle/Scala functionality; the resulting 🍋‹class› or 🍋 🪙‹ A more convenient high-level approach works via 🍋‹etc/build.props› (see \secref{sec:scala-build}). › ‹}? (@{sntax prop}+) + @'and' ‹Component configuration via 🍋‹etc/build.props›› ‹ Isabelle components may augment the Isabelle/Scala/Java environment declaratively via properties given in 🍋‹etc/build.props› (within the component directory). This specifies an output 🍋 Scala or Java 🪙‹ specify 🪙 🍋‹isabelle.Isabelle_System.Service›; these have a particular meaning to Isabelle/Scala tools. Before running a Scala or Java process, the Isabelle system implicitly ensures that all provided modules are compiled and packaged (as jars). It is also possible to invoke @{tool scala_build} explicitly, with extra options. 🪙 The syntax of 🍋‹ file🪙‹🪙‹ but the encoding is 🍋‹UTF-8›, instead of historic 🍋‹ documentation. The subsequent properties are relevant for the Scala/Java build process. Most properties are optional: the default is an empty string (or list). File names are relative to the main component directory and may refer to Isabelle riables (e.g \\^v>\open$ISABELLE_HOM› ▪ 🍋‹ in printed messages. ▪ 🍋 of the specified sources (and resources). If this is absent (or 🍋‹no_build› is set, as described below), there is no implicit buildinsta. th n process. The contributing sources might be given nonetheless, notably for @{tool scala_project} (\secref{sec:tool-scala-project}), which includes Scala/Java sources of components, while suppressing 🍋‹jar› modules (to ▪ 🍋‹no_build› is a Boolean property, with default 🍋‹false›:cases-iduct}. Unlik 🍋‹true› --- it is assumed to be provided by other means. ▪ 🍋‹scalac_options› @{setting_ref ISABELLE_SCALAC_OPTIONS} and @{setting_ref ISABELLE_JAVAC_OPTIONS} for this component; option syntax follows the regular command-line tools 🍋‹scalac› ▪ 🍋descr> @method (HOL) ind_cases} nd @comma HOL "i"} pr only relevant for direct invocation like ``🍋‹› ▪ 🍋‹requirements› is a list of \<^ compilation process, but not provided by the regular classpath (notably @{setting ISABELLE_CLASSPATH}). A 🪙‹ settings variables as usual. E.g. 🍋‹$ISABELLE_SCALA_JAR› for the main 🍋"} add-on modules). A 🪙‹special entry› is of the form 🍋‹env:›‹variable› and refers to a settings variable from the Isabelle environment: its value may consist of multiple 🍋‹jar› entries (separated by colons). Environment variables are not e r. ▪ 🍋‹resources› is a list of files that should be included in the resulting 🍋‹jar› file. Each item consists of a pair separated by colon: ‹ the component directory) to the given target file or directory (relative to the 🍋‹jar› abbreviates ‹ relative path name. ▪ the specified module. It is possible to use both languages simultaneously: the Scala and Java compiler will be invoked consecutively to make this work. ▪ 🍋 service providers (subclasses of 🍋‹isabelle.Isabelle_System.Service›). Internal class names of the underlying JVM need to be given: e.g. see method @{scala_method (in java.lang.Object) getClass}. Particular services require particular subclasses: instances are filtered according to their dynamic type. For example, class 🍋 tools, and class 🍋‹isabelle.Scala.Functions› functions (\secref{sec:scala-functions}). › \openExplicit Isabelle/S/Scala/Java bui \label{sec:tool-scala-build}› ‹ The @{tool_def scala_build} tool explicitly invokes the build process for all registered components. @{verbatim [display] ‹ Options are: -f force fresh build -q quiet mode: suppress stdout/stderr Build Isabelle/Scala/Java modules of all registered components (if required). ›} For each registered Isabelle component that provides 🍋‹ the corresponding input 🍋‹requirements› required, there is an automatic build using 🍋‹scalac› or 🍋‹javac› The identity of input files is recorded within the output 🍋‹jar› digests in 🍋‹META-INF/isabelle/shasum›. 🪙 Option 🍋‹-f› forces a fresh build, regardless of the up-to-date status of input files vs. the output module. 🪙 Option 🍋 Java compiler. 🪙 Explicit invocation of @{toolf names for newlocal applications with special options: the Isabelle system normally does an automatic the build on demand. › ‹Project setup for common Scala IDEs \label{sec:tool-scala-project}› ‹ The @{tool_def scala_project} tool creates a project configuration for all Isabelle/Java/Scala modules spe 🍋‹etc/build.props› the command-line: @{verbatim [display] ‹Usage: isabelle scala_project [OPTIONS] [MORE_SOURCES ...] Options are: -D DIR project directory (default: "$ISABELLE_HOME_USER/scala_project") -G use Gradle as build tool -L make symlinks to original source files -M use Maven as build tool -f force update of existing directory -v verbose Setup project for Isabelle/Scala/jEdit --- to support common IDEs such as IntelliJ IDEA. Either option -G or -M is mandatory to specify the build tool.›} The generated configuration is for Gradle🪙‹🪙‹https://gradle.org›. Maven🪙 into common IDEs like IntelliJ IDEA🪙‹🪙 This allows to explore the sources with static analysis and other hints in real-time. The generated files refer to physical file-system locations, using the path notation of the underlying OS platform. Thus the project needs to be recreated whenever the Isabelle installation is changed or moved. 🪙 Option 🍋‹ tool: either one needs to be specified explicitly. These tools have a tendency to break down unexpectedly, so supporting both increases the chances that the generated IDE project works properly. 🪙 Option 🍋‹ develop Isabelle/Scala/jEdit modules within an external IDE. The default is to 🪙‹copy› effect on the originals. 🪙 Option 🍋‹ 🍋‹$ISABELLE_HOME_USER/scala_project›. Option 🍋‹ project directory to be 🪙‹purged›‹ been generated by @{tool "scala_project"} before. 🪙 Option 🍋‹-v› enables verbose mode. › ‹Examples› ‹ Create a project directory and for editing the original sources: @{verbatim [display] ‹isabelle scala_project -f -L›} On Windows, this usually requires Administrator rights, in order to create native symlinks. › ‹Registered Isabelle/Scala functions \label{sec:scala-functions}› ‹Defining functions in Isabelle/Scala›^emph>‹ ‹ The service class 🍋‹isabelle.Scala.Functions›eview and \<emph\ functions of type 🍋‹isabelle.Scala.Fun›: by registering instances via 🍋‹ (\secref{sec:scala-build}), it becomes possible to invoke Isabelle/Scala from Isabelle/ML (see below). An example is the predefined collection of 🍋‹isabelle.Scala.Functions› in 🍋 is accessible in Isabelle/Scala as 🍋‹isabelle.Scala.functions›. The general class 🍋‹ / multi-result function 🍋‹<> instances of 🍋‹isabelle.Scala.Fun_Strings› for type 🍋‹List[String] => List[String]›, or \<^scala_type\ 🍋‹String => String›. › ‹Invoking functions in Isabelle/ML› ‹ Isabelle/PIDE provides a protocol to invoke registered Scala functions in ML: this works both within the Prover IDE and in batch builds. The subsequent ML antiquotations refer to Scala functions in a formally-checked manner. \begin{matharray}{rcl} @{ML_antiquotation_def "scala_function"} & : & ‹‹ @{ML_antiquotation_def "scala"} & : & ‹ML_antiquotation› \\ \end{matharray} 🪙‹ java.lang.StringIndexOutOfBoundsException: Index 72 out of bounds for length 72 @{ML_antiquotation scala}) @{syntax embedded} › 🪙 ‹@{scala_function name}›^sup>*<> literal. 🪙 ‹@{scala name}› and ‹@{scala_thread name}› invoke the checked function via PIDE protocol. In Isabelle/ML his appears afunc of t ty 🪙‹string list -> string list› or 🪙‹string -> string›, depending on the definition in Isabelle/Scala. Evaluation is subject to interrupts within the ML runtime environment as usual. A 🍋‹null› result in Scala raises an exception 🪙‹ of ‹@{scala}› works via a Scala future on a bounded thread farm, while ‹@{scala_thread}› always forks a separate Java/VM thread. The standard approach of representing datatypes via strings works via XML in YXML transfer syntax. See Isabelle/ML operations and modules @{ML YXML.string_of_body}, @{ML YXML.parse_body}, @{ML_structure XML.Encode}, @{ML_structure XML.Decode}; similarly for Isabelle/Scala. Isabelle symbols may have to be recoded via Scala operations 🍋 🍋‹isabelle.Symbol.encode›. › ‹> theory› ‹ Invoke the predefined Scala function 🍋‹echo›: ‹ val s = "test"; val s' = 🍋‹ 🍋 (s = s') › ‹ Let the Scala compiler process some toplevel declarations, producing a list of errors: › \<open val source = "class A(a: Int, b: Boolean)" val errors = 🍋‹scala_toplevel›) code_timing} & : : & |> YXML.parse_body |> let open XML.Decode in list string end; 🍋 (null errors)› ‹ The above is merely for demonstration. See 🪙‹Scala_Compiler.toplevel› for a more convenient version with builtin decoding and treatment of errors. java.lang.StringIndexOutOfBoundsException: Index 19 out of bounds for length 8 ‹ ‹ The subsequent document antiquotations help to docu sa/Scala entities, with formal checking of names against the Isabelle classpath. \begin{matharray}{rcl} @{antiquotation_def "scala"} & : & ‹antiquotation› \\ @{antiquotation_def "scala_object"} & : & ‹ @{antiquotation_def "scala_type"} & : & ‹antiquotation› \\ @{antiquotation_def "scala_method"} & : & ‹ \end{matharray} 🪙 (@@{antiquotation scala} | @@{antiquotation scala_object}) @{syntax embedded} ; @@{antiquotation scala_type} @{syntax embedded} types ; @@{antiquotation scala_method} class @{syntax embedded} types args ; class: ('(' @'in' @{syntax name} types ')')? ; types: ('[' (@{syntax name} ',' +) ']')? ; args: ('(' (nat | (('_' | @{syntax name}) + ',')) ')')? › 🪙 ‹@{scala s}› checked by the Scala compiler as toplevel declaration (without evaluation). This allows to write Isabelle/Scala examples that are statically checked. 🪙 ‹@{scala_object x}› ground module) and prints the result verbatim. 🪙 parameters) and prints the result verbatim. 🪙 the context of class ‹c› a number ‹n› type variables specified for the class or method: ‹A› Everything except for the method name ‹ class context means that this is a static method. The absence of arguments with types means that the method can be determined uniquely as 🍋 in Scala (no overloading). › ‹Examples›pat@syytxedded} ‹ Miscellaneous Isabelle/Scala entities: ▪‹isabelle.Isabelle_Process› ▪ type without parameter: @{scala_type isabelle.Console_Progress} ▪ type with parameter: @{s | 'drop:' cnst+) | 'drop' | 'abort:' (const+) | bor') ▪ static method: 🍋‹ ▪ class and method with type parameters: @{scala_method (in List[A]) map[B]("A => B")} ▪ overloaded method with argument type: @{sc ›
¤ Dauer der Verarbeitung: 0.12 Sekunden (vorverarbeitet am 2026-06-10) ¤*© Formatika GbR, Deutschland |
|
||||||||||||||
2026-06-09