doc-src/isac/CTP-userinterfaces.tex
branchdecompose-isar
changeset 38089 042b19985ea0
parent 38079 431344850e40
child 38090 4e128838c313
equal deleted inserted replaced
38087:d45fae3237f1 38089:042b19985ea0
     7 
     7 
     8 \def\isac{${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}
     8 \def\isac{${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}
     9 \def\sisac{{\footnotesize${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
     9 \def\sisac{{\footnotesize${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
    10 \def\Problem{ {\tt Problem }}
    10 \def\Problem{ {\tt Problem }}
    11 
    11 
    12 \title{Upcoming Userinterfaces for Computer Theorem Provers.\\
    12 \title{Userinterfaces for Computer Theorem Provers.\\
    13 	The case of Isabelle
    13 	Contributions to Isabelle
    14 }
    14 }
    15 
    15 
    16 \author{G. Schafhauser, A. Schulhofer, M. Steger\\
    16 \author{G. Schafhauser, A. Schulhofer, M. Steger\\
    17 Knowledge Management Institute (KMI)\\
    17 Knowledge Management Institute (KMI)\\
    18 TU Graz}
    18 TU Graz}
    29 
    29 
    30 %Georg
    30 %Georg
    31 \section{State of the art in CTP Interfaces}
    31 \section{State of the art in CTP Interfaces}
    32 
    32 
    33 \subsection{A European technology: Coq and Isabelle}\label{ctp-techn}
    33 \subsection{A European technology: Coq and Isabelle}\label{ctp-techn}
    34      http://en.wikipedia.org/wiki/Coq\\
    34 %     http://en.wikipedia.org/wiki/Coq\\
    35      http://coq.inria.fr/
    35 %     http://coq.inria.fr/
    36 
    36 %
    37      http://en.wikipedia.org/wiki/Isabelle\_(theorem\_prover)\\
    37 %     http://en.wikipedia.org/wiki/Isabelle\_(theorem\_prover)\\
    38      http://isabelle.in.tum.de/index.html
    38 %     http://isabelle.in.tum.de/index.html
    39 
    39 %
    40 why math -- functional: some of the languages have been specifically designed for constructing software for symbolic computation (SC). 
    40 %why math -- functional: some of the languages have been specifically designed for constructing software for symbolic computation (SC). 
    41 %+ required for \ref{ml-users}
    41 %%+ required for \ref{ml-users}
    42 
    42 %
    43 SC http://en.wikipedia.org/wiki/Symbolic\_computation
    43 %SC http://en.wikipedia.org/wiki/Symbolic\_computation
    44 % mainly does not compute numerical values, but terms containing variables like functions (symbols)
    44 %% mainly does not compute numerical values, but terms containing variables like functions (symbols)
    45 
    45 %
    46 The LCF project
    46 %The LCF project
    47 http://hopl.murdoch.edu.au/showlanguage.prx?exp=8177
    47 %http://hopl.murdoch.edu.au/showlanguage.prx?exp=8177
    48 specifically designed a 'meta language' (ML)
    48 %specifically designed a 'meta language' (ML)
    49 http://en.wikipedia.org/wiki/ML\_(programming\_language)
    49 %http://en.wikipedia.org/wiki/ML\_(programming\_language)
    50 \cite{pl:milner97}
    50 %\cite{pl:milner97}
    51 for developing CTP
    51 %for developing CTP
    52  
    52 \subsubsection{Standard ML}
    53 
    53 Standard ML is a general-purpose, modular, functional programming language. 
       
    54 Programs written in Standard ML consist of expressions to be evaluated, as opposed to statements or commands. 
       
    55 SML is a modern descendant of the ML programming language used in the Logic for Computable Functions (LCF) theorem-proving project. 
       
    56 It is invented by Robin Milner. %http://en.wikipedia.org/wiki/Standard_M 
       
    57 \subsubsection{Coq}
       
    58 Coq is an interactive theorem prover, developed in France. The team leader is Senior Scientist Benjamin Werner. 
       
    59 Coq is in Objective Caml programmed, an ML based programming language.
       
    60 It has the ability to express  mathematical  assertions and check proof of mathematical  assertions. 
       
    61 Furthermore Coq includes automatic theorem proving tactics and decision procedures.
       
    62 Proof development in Coq is done through a language of tactics that allows a user-guided proof process. 
       
    63 At the end, the user can check that tactics build lambda-terms. 
       
    64 Another feature of Coq is “that it can automatically extract executable programs from specifications, as either Objective Caml 
       
    65 or Haskell source code.“
       
    66 Properties, programs and proofs are written a language called the Calculus of Inductive Constructions (CIC).
       
    67 Coq is based on a type-checking algorithm, therefore Coq uses only typing judgements.
       
    68 Coq supports a functional programming language.
       
    69 (http://coq.inria.fr/a-short-introduction-to-coq)
       
    70 \subsubsection{Isabelle}
       
    71 Isabelle is an interactive theorem proving framework for high-level natural deduction proofs \cite{Paulson:Isa94}, written in Standard ML. 
       
    72 Isabelle is developed at University of Cambridge (Larry Paulson), Technische Universität München (Tobias Nipkow) 
       
    73 and Université Paris-Sud (Makarius Wenzel).
       
    74 The most widespread instance of Isabelle nowadays is Isabelle/HOL, providing a higher-order logic theorem proving environment.
       
    75 Isabelle/HOL includes several  specification tools, e.g. for datatypes, inductive definitions and functions with complex pattern matching.
       
    76 Proofs are written in the structured proof language Isar. Isabelle implements several tools to increase the user's productivity in theorem proving. 
       
    77 Isabelle's classical reasoner is used to check formulas. The simplifier can reason with and about equations. 
       
    78 Linear arithmetic facts are proved automatically.
       
    79 Isabelle provides notational support: new notations can be introduced, using normal mathematical symbols.
       
    80 Definitions and proofs may include LaTeX source, from which Isabelle can automatically generate typeset documents.
       
    81 Isabelle/HOL allows to turn executable specifications directly into code in SML, OCaml, and Haskell.
       
    82 (http://www.cl.cam.ac.uk/research/hvg/Isabelle/overview.html)
    54 \subsection{Userinterfaces for CTP: Coq and Isabelle}\label{gui-coq-isa}
    83 \subsection{Userinterfaces for CTP: Coq and Isabelle}\label{gui-coq-isa}
    55      CoqIDE, ..
    84 %     CoqIDE, ..
    56          http://coq.inria.fr/what-is-coq?q=node/57\\
    85 %         http://coq.inria.fr/what-is-coq?q=node/57\\
    57          earlier than Isabelle/jEdit
    86 %         earlier than Isabelle/jEdit
    58 
    87 %
    59      ProofGeneral for Isabelle
    88 %     ProofGeneral for Isabelle
    60          http://proofgeneral.inf.ed.ac.uk/\\
    89 %         http://proofgeneral.inf.ed.ac.uk/\\
    61          emacs stone age ?
    90 %         emacs stone age ?
       
    91 \subsubsection{Coq Integrated Development Environment}
       
    92 CoqIde is a graphical interface for Coq. It is written in Ocaml. (http://coq.inria.fr/cocorico/CoqIde)
       
    93 Its main purpose is to allow the user to navigate forward and backward into a Coq vernacular file, 
       
    94 executing corresponding commands or undoing them respectively. 
       
    95 There are several  buffers for helping to write proof scripts.
       
    96 Among all these buffers, there is always one which is the current running buffer, whose name is displayed on a green background,
       
    97 which is the one where Coq commands are currently executed. 
       
    98 Buffers may be edited as in any text editor, and classical basic editing commands (Copy/Paste, ...) are available.  
       
    99 CoqIde provides also a feedback system for the user. 
       
   100 Therefore the background is green when a command succeeds, otherwise an errormessage is displayed in the message window and the error location is underlined red.
       
   101 CoqIDE offers only basic editing commands, therefore it is possible to launch another more sophisticated text editor. 
       
   102 Furthermore CoqIde provides a proof wizard “for automatically trying to solve the current goal using simple tactics.”
       
   103 Another features of this IDE are the customization options, which can be accessed by the Edit menu. 
       
   104 This allows the user to change the apeareance of the IDE.
       
   105 
       
   106 
       
   107 \begin{figure}[htbp]
       
   108 \centering
       
   109 %\includegraphics[bb=0 0 10 10]{coqide.png}
       
   110 \includegraphics[scale=0.25]{fig/coqide}
       
   111 \caption{CoqIDE main screen}
       
   112 \end{figure}
       
   113 
       
   114 
       
   115 (http://coq.inria.fr/V8.1/refman/Reference-Manual016.html)
       
   116 \subsubsection{Proof General for Isabelle}
       
   117 Proof General is a generic front-end for proof assistants, based on the customizable text editor Emacs.
       
   118 Proof General has been developed at the LFCS in the University of Edinburgh with contributions from other sites.
       
   119 Proof General comes ready-to-go for these proof assistants: Isabelle, Coq, PhoX, LEGO.
       
   120 Proof General is used to write proof scripts. A Proof Script is a sequence of commands sent to theorem prover. 
       
   121 The communication between the user and the theorem prover takes place via two or  more Emacs text widgets. 
       
   122 Therefore the user sees only the output from the latest proof step.(proofgeneral.ps.gz)
       
   123 
       
   124 
       
   125 Isabelle/Isar Proof General has full support for multiple file scripting, with dependencies between theories communicated between Isabelle and Proof General. 
       
   126 There is full support for Unicode Tokens, using the Isabelle print mode for X Symbol tokens. Many Isabelle theories have X Symbol syntax already defined 
       
   127 and it's easy to add to your own theories. 
       
   128 (http://proofgeneral.inf.ed.ac.uk/fileshow.php?file=releases%2FProofGeneral%2Fisar%2FREADME)
       
   129 \begin{figure}[htbp]
       
   130 \centering
       
   131 \includegraphics[scale=0.5]{fig/pgisabelle}
       
   132 \caption{Proof General for Isabelle}%
       
   133 \end{figure}
       
   134 \subsubsection{Isabelle/Jedit}
       
   135 jEdit is a text editor for programmers, written in Java.
       
   136 Compared to fully-featured IDEs, such as Eclipse or Netbeans, jEdit is much 
       
   137 smaller and better focused on its primary task of text editing.
       
   138 The general look of the Isabelle/jEdit plugin is similar to existing Java IDEs.
       
   139 The main Isabelle/jEdit plugin consists of ≈ 10 small Scala files  that augment some key jEdit components in order to provide a metaphor of asynchronous 
       
   140 proof document editing. 
       
   141 Isabelle/jEdit integrates the jEdit 4.3.2 framework  and some further  jEdit plugins. 
       
   142 It also implements custom-made IsabelleText Unicode font that actually contains the usual Isabelle symbols that users expect from long 
       
   143 years of Proof General X-Symbol support. 
       
   144 The editor provides useful feedback, via semantic information from the processed document in the background. 
       
   145 This achieves continuous proof checking based on our 
       
   146 asynchronous prover toplevel. A lot of information can be directly attached 
       
   147 to the source text, via coloring, tooltips, popups etc.
    62 
   148 
    63 \subsection{Upcoming requirements for userinterfaces in CTP}\label{gui-requir}
   149 \subsection{Upcoming requirements for userinterfaces in CTP}\label{gui-requir}
    64      @ interaction close to tty (Telegraph)\\
   150 %     @ interaction close to tty (Telegraph)\\
    65        BUT: separate parts in {\em one} proof could be processed in parallel
   151 %       BUT: separate parts in {\em one} proof could be processed in parallel
    66 
   152 %
    67      @ http://www.informatik.uni-bremen.de/uitp/
   153 %     @ http://www.informatik.uni-bremen.de/uitp/
    68 
   154 %
    69      @ ... see\\
   155 %     @ ... see\\
    70        http://www4.in.tum.de/~wenzelm/papers/async-isabelle-scala.pdf,\\
   156 %       http://www4.in.tum.de/~wenzelm/papers/async-isabelle-scala.pdf,\\
    71        http://www4.in.tum.de/~wenzelm/papers/parallel-isabelle.pdf
   157 %       http://www4.in.tum.de/~wenzelm/papers/parallel-isabelle.pdf
    72 
   158 After several decades, most proof assistants are still centered around TTY-based(Fußnote)  interaction in a
       
   159 tight read-eval-print loop. All Emacs-based GUI's for CTPs follow this synchronous
       
   160 model based on single commands with immediate response, meaning that the editor waits for the
       
   161 prover after each command. As to multicore politics of leading semiconductor chip manufacturer,  parallelism in software technology has become very popular. 
       
   162 Therefore the support of parallelism in CTP technology could improve the performance and the multiuser support. 
       
   163 So it is necessary to use proof documents instead of proof scripts.  
       
   164 Proof scripts are  sequences of commands however proof documents are  structured texts. 
       
   165 So the proof document idea seems to guarantee the perfect support for parallelism in the CTP technology. 
       
   166 (MW async-isabelle-scala.pdf)
       
   167 \newpage
    73 %Andreas
   168 %Andreas
    74 \section{Isabelle's plans for new user-interfaces}\label{gui-plans}
   169 \section{Isabelle's plans for new user-interfaces}\label{gui-plans}
    75        http://www4.in.tum.de/~wenzelm/papers/async-isabelle-scala.pdf,\\
   170 %       http://www4.in.tum.de/~wenzelm/papers/async-isabelle-scala.pdf,\\
    76        http://www4.in.tum.de/~wenzelm/papers/parallel-isabelle.pdf
   171 %       http://www4.in.tum.de/~wenzelm/papers/parallel-isabelle.pdf
    77 
   172 %
    78 theorem proving will be integrated into software development
   173 %theorem proving will be integrated into software development
    79 
   174 %
    80 hundreds of proof obligations are generated during a software verification process 
   175 %hundreds of proof obligations are generated during a software verification process 
    81 
   176 %
    82 so the final goald of Isabelle's planning is integration with other software development tools in an integrated development environment (IDE).
   177 %so the final goald of Isabelle's planning is integration with other software development tools in an integrated development environment (IDE).
    83 
   178 %
    84 still many principal issues need to be clarified with respect to integration of CTP and other development tools. So engaging into details makes no sense at the present, and Isabelle will approach the final goal via experimental intermediate steps of integration.
   179 %still many principal issues need to be clarified with respect to integration of CTP and other development tools. So engaging into details makes no sense at the present, and Isabelle will approach the final goal via experimental intermediate steps of integration.
       
   180 
       
   181 \begin{itemize}
       
   182 \item theorem proving will be integrated into software development
       
   183 \item hundreds of proof obligations are generated during a software verification process
       
   184 \item so the final goal of Isabelle's planning is integration with other software development tolls in an integrated development environment (IDE)
       
   185 \item still many principal issues need to be clarified with respect to integration of CTP and other development tools. So engaging into details makes no sense at the present, and Isabelle will approach the final goal via experimental intermediate steps of integration
       
   186 \item favorite IDE is the jEdit, because it is clearer than Eclipse or NetBeans. The reason behind this choice follows in section 4.2
       
   187 \end{itemize}
    85 
   188 
    86 \subsection{Connect ML-world to the users' world via JVM}\label{ml-users}
   189 \subsection{Connect ML-world to the users' world via JVM}\label{ml-users}
    87 In Sect.\ref{ctp-techn} reasons have been given, why mathematics software at the state-of-the-art cannot be written in Java or the like. On the other side, Sect.\ref{gui-requir} stated requirements for mathematical user interfaces, which cannot be accomplished by ML-like languages. These requirements can be best accomplished by languages like Java, which have powerful libraries available for convenient assembly of GUIs.
   190 In Sect.\ref{ctp-techn} reasons have been given, why mathematics software at the state-of-the-art cannot be written in Java or the like. On the other side, Sect.\ref{gui-requir} stated requirements for mathematical user interfaces, which cannot be accomplished by ML-like languages. These requirements can be best accomplished by languages like Java, which have powerful libraries available for convenient assembly of GUIs.
       
   191 
       
   192 
       
   193 
    88 
   194 
    89 \paragraph{Example: a functional mathematics engine} as the experimental one in the \sisac-project is given by the following signature:
   195 \paragraph{Example: a functional mathematics engine} as the experimental one in the \sisac-project is given by the following signature:
    90 {\it
   196 {\it
    91 \begin{tabbing}
   197 \begin{tabbing}
    92 \=xx\=xxxxxxxxxxxxxxxxxxxxxxxxx\=\kill
   198 \=xx\=xxxxxxxxxxxxxxxxxxxxxxxxx\=\kill
   107 The three essential functions are \textit{do\_next}, which reads a \textit{program} for determining the next \textit{step} in a calculation, the function \textit{apply\_tactic}, which applies a \textit{tactic} input by the user to the current \textit{position} in a calculation and thus may produce a list of \textit{step}s and the function \textit{apply\_formula}, which applies an input \textit{formula} accordingly.
   213 The three essential functions are \textit{do\_next}, which reads a \textit{program} for determining the next \textit{step} in a calculation, the function \textit{apply\_tactic}, which applies a \textit{tactic} input by the user to the current \textit{position} in a calculation and thus may produce a list of \textit{step}s and the function \textit{apply\_formula}, which applies an input \textit{formula} accordingly.
   108 
   214 
   109 Now, the point with functional programming is, that the functions do {\em not} cause persistent updates in some memory, rather: all three functions above take the current state of the calculation, \textit{calcstate}, as an argument and after they have done they work return the updated \textit{calcstate}.
   215 Now, the point with functional programming is, that the functions do {\em not} cause persistent updates in some memory, rather: all three functions above take the current state of the calculation, \textit{calcstate}, as an argument and after they have done they work return the updated \textit{calcstate}.
   110 
   216 
   111 There are several advantages of this kind of programming: more straight forward verification, which is not discussed here, and other features. For instance, given the three functions above, it is easy to undo steps of calculations, or go back to an earlier step of calculations: one just needs to store the \textit{calcstate}s (in a list), even without knowing the details of the \textit{calcstate}, which thus can be encapsulated for internal access only.
   217 There are several advantages of this kind of programming: more straight forward verification, which is not discussed here, and other features. For instance, given the three functions above, it is easy to undo steps of calculations, or go back to an earlier step of calculations: one just needs to store the \textit{calcstate}s (in a list), even without knowing the details of the \textit{calcstate}, which thus can be encapsulated for internal access only.
   112 
   218 %
   113 \paragraph{Example: an object-oriented wrapper} as required for embedding the above mathematics engine into an object-oriented system. Such a wrapper looks like this:
   219 %\paragraph{Example: an object-oriented wrapper} as required for embedding the above mathematics engine into an object-oriented system. Such a wrapper looks like this:
   114 
   220 %
   115 TODO
   221 %TODO
   116 
   222 
   117 \subsection{Scala as a mediator between ML and JVM}\label{scala-medi}
   223 \subsection{Scala as a mediator between ML and JVM}\label{scala-medi}
   118 {\em new} language --- what for, ideas ...
   224 {\em new} %language --- what for, ideas ...
       
   225 Scala is a hybrid multi-paradigm programming language. It combines object-oriented programming and functional programming. Scala runs on the Java Virtual Machine and is byte-code compatible with existing Java programs. The compilation model of Scala is nearly the same as the Java's model. So existing tools, libraries and applications can be used with Scala. The Syntax of Scala is similar to Java and ML. A number of keywords plus the block syntax is adopted from Java and from ML the syntax for type annotation and declaration. The source-code is typically reduced, concisely and more compact compared to equivalent Java code.\\
       
   226 Scala is pure object-oriented, this means every value is an object. The same is true for primitive data types, because compiler-generated byte code is using primitive data types. Known design patterns from OOP can be used with Scala as well. Data types and behaviors of objects are described by classes and traits [wiki]. Traits not only consist of definitions, they also can contain implementations of methods. To avoid the problems of multiple inheritance, classes are able to extend various traits, this is a flexible mixin-based mechanism. The keyword Object is used to implement a Singleton-Class. \\
       
   227 In Scala every function is a value, hence Scala is also a functional language. Functions in Scala are first-class objects, this means it is possible to pass a function as a parameter, return a function from a subroutine, or assign to a variable. Scala also supports case classes, which are used for pattern matching. Case classes are regular classes which export their constructor parameters[wiki-11-1s]. Furthermore Scala supports higher-order functions, currying and allows functions to be nested. \\
       
   228 Scala is more statically typed than Java, but is able to infer types by usage. So most static type declarations are optional. This static type system ensures a safe and coherent use of abstraction. Scala supports:
       
   229 \\
       
   230 \begin{itemize}
       
   231 \item generic classes
       
   232 \item variance annotations
       
   233 \item upper and lower type bounds
       
   234 \item classes and abstract types as object members
       
   235 \item compound types
       
   236 \item explicitly typed self references
       
   237 \item views
       
   238 \item polymorphic methods
       
   239 \end{itemize}
       
   240 Static types need no explicit declaration but can be given to give the code some clarity.\\\\
       
   241 Scala supports threads, but the Scala library contains an actor model inspired from Erlang. Concurrency and Scala actors follow in the next section.\\
       
   242 
       
   243 %quellen
       
   244 %%http://de.wikipedia.org/wiki/Scala_%28Programmiersprache%29
       
   245 %%http://en.wikipedia.org/wiki/Scala_%28programming_language%29
       
   246 %%http://creativekarma.com/ee.php/weblog/comments/why_scala_instead_of_java/
       
   247 %%http://www.scalasolutions.com/scala
       
   248 
   119 
   249 
   120 \subsection{Support for parallel processing}\label{actors}
   250 \subsection{Support for parallel processing}\label{actors}
   121 actors copied from erlang
   251 %actors copied from erlang
       
   252 
       
   253 Concurrency has lately become more and more attention, because multicore processors make concurrency very important for efficient program execution, by running multiple threads parallel and so concurrent programming gets indispensable and distributed computing,web services and mobile environments are naturally concurrent. \\
       
   254 A very attractive model, because of the fact that it might addresses multicore processors and several techniques which are basically concurrent, is message-based concurrency. Most of the message passing systems, which are used in practice, are based on the actor model. \\
       
   255 An actor is a concurrent process that executes a function. The state of an actor gets never shared, so it doesn't need to compete for locks of shared data. Actors own a mailbox where incoming messages are stored in. A mailbox is mainly a queue with several producers and one consumer, which are other actors. Actors share data by sending Messages which are sent asynchronously. Messages are unchangeable, so they don't require a lock and are used for communication between actors. By creating new actors, by sending messages to known actors, or changing its behavior, an actor is able to reply to a message. The actor-based process is combined with pattern matching for messages.\\
       
   256 The Erlang programming language is a functional programming language and a very popular implementation of message-based concurrency, which operates with actors. It was developed for real-time control systems. Such systems are telephone exchanges, network simulators and distributed resource controllers [IoC]. These systems use a very lightweight implementation and a large number of concurrent processes, which can active simultaneously.\\
       
   257 Operating system threads and threads of virtual machines, are too heavyweight for the implementation of such processes. The standard concurrency for mainstream platforms where shared-memory threads with locks. Such a platform is the Java Virtual Machine (JVM), which suffers from high memory consumption and context-switching overhead.
       
   258 The main reasons are:
       
   259 \begin{enumerate}
       
   260 \item quick exhaustion of virtual address space
       
   261 \item locking mechanisms often lack suitable contention managers
       
   262 \end{enumerate}
       
   263 %[IoC]
       
   264 For that reasons Erlang uses lightweight concurrent processes by its own run time system and not by the underlying operating system [IoC] and the computations on these platforms are often modeled in an event-driven style, which is complicated and error-prone.
       
   265 \paragraph{Two different strategies for concurrency} are being used for implementation. This two strategies often follow different programming models, the benefit of thread-based models is that they are easier to use, but they still suffer from the memory consumption and the context-switching. The event-based models are just the opposite of the thread-based, they are more efficient, but in massive designs they are very difficult.
       
   266 
       
   267 \subparagraph{Thread-based implementation:} The behavior of a concurrent process is defined by implementing a thread-specific method. The execution state is maintained by an associated thread stack [2.P].
       
   268 Supports blocking operations and can be executed on multicore processors in parallel.
       
   269 
       
   270 \subparagraph{Event-based implementation:} The behavior is defined by a number of (non-nested) event-handlers which are called from inside an event loop. The execution state of a concurrent process is maintained by an associated record or object [2.P]. Targets to a large number of actor which can be active simultaneously, because they are more lightweight.
       
   271 
       
   272 \paragraph{Actors in Scala} are based on actors in Erlang. Scala uses the basic thread model of Erlang, but on the other hand all higher-level functions got implemented in the Scala library as classes or methods. The Scala-actors are a unification of the concurrent process implementation models, mentioned above and they are compatible with normal Virtual Machine thread. Normal VM threads can use the same communication and monitoring capabilities, because they are treated like an actor. A message-based concurrency seems to be more secure than shared-memory with locks, because accessing an actor's mailbox is race-free. The advantage of a implementation in a library is that it can be flexibly extended and adapted to new needs. The library makes use of Scala abstraction opportunities, like partial functions and pattern matching.
       
   273 
       
   274 The main idea of this model is that an actor is able to wait for a message by using two different operations, which try to remove a message from the current actor's mailbox. To do so, a partial function must be given to the operation, that specifies a set of message patterns. These operations are receive and react. An actor can suspend with a full thread stack (receive) or it can suspend with just a continuation closure (react) [2.P]. The first operation of an actor to wait for an message is equal to thread-based programming and the second operation to event-based programming.
       
   275 
       
   276 receive:         def receive[R](f: PartialFunction[Any, R]): R
       
   277 The current actor's mailbox get scanned and if there is one message which matches one of the patterns declared in the partial function, the message is removed from the mailbox and the partial function is applied to the message, the result is returned. Otherwise the current thread blocks. Thus the receiving actor has the ability to execute normally when receiving a message which matches.  Note that receive retains the complete call stack of the receiving actor; the actor’s behavior is therefore a sequential program which corresponds to thread-based programming [2.P]. \\
       
   278 react:          
       
   279 $$\mathit{def}\;\mathit{react}(f: \mathit{PartialFunction}[Any, Unit]): \mathit{Nothing}$$
       
   280 The action which is specified in the partial function is the last code that the current actor executes, if the message is matching. The partial function gets registered by the current actor and the underlying thread gets released. React has the return type Nothing, this means that the method never returns normally. When the actor receives a matching message, the earlier registered partial function gets called and the actor's execution gets continued. The partial function f which corresponds to a set of event handlers [2.P]. \\
       
   281 For this implementation multiple acotrs are executed by multiple threads and therefore a thread pool is used. Whenever it is necessary the pool can be re sized, to support the operations of the thread-based and event-based model. If only operations of the event-based model are executed then the thread pool could be fixed. To avoid system-included deadlocks, if some actors use thread-based operations, the thread pool has to grow, because if there are outstanding tasks and every worker thread is occupied by a blocked actor, new threads are necessary. \\
       
   282 Since the communication between actors takes place through asynchronous message passing, asynchronous operations get executed, tasks have to be created and submitted to a thread pool for execution. A new task is created, when an actor spawns a new actor or a message, which enables an actor to continue, is send to an actor which is suspended in a react operation or by calling react, where a message can be immediately removed from the mailbox.\\
       
   283 Event-Based Programming without Inversion of Control - Philipp Haller, Martin Odersky  [IoC]\\
       
   284 Scala actors: Unifying thread-based and event-based programming - Philipp Haller, Martin Odersky [2.P]\\
       
   285 
   122 
   286 
   123 % Marco
   287 % Marco
   124 \section{Planned contributions at TU Graz}
   288 \section{Planned contributions at TU Graz}
   125 
   289 
   126 \subsection{Make Isabelle process structured derivations}\label{struct-der}
   290 \subsection{Make Isabelle process structured derivations}\label{struct-der}
   145 The plan is to use the machinery provided Isabelle/Isar as a 'logical operating system' ~\cite{isar-impl} and adapt the machinery such that is accepts SC in parallel to the Isar proof language~\cite{wenzel:isar}.
   309 The plan is to use the machinery provided Isabelle/Isar as a 'logical operating system' ~\cite{isar-impl} and adapt the machinery such that is accepts SC in parallel to the Isar proof language~\cite{wenzel:isar}.
   146 
   310 
   147 This plan involves the following details.
   311 This plan involves the following details.
   148 
   312 
   149 \subsection{Add a plug-in to jEdit}\label{plugin}
   313 \subsection{Add a plug-in to jEdit}\label{plugin}
   150      file structure, copied from example project ...
   314     % file structure, copied from example project ...
       
   315 %Die von jEdit verfolgte Strategie im Bezug auf Plugin-Management und natürlich generell die totale Offenlegegung des Codes ist für ein Projekt wie Isabelle und auch für das Isac-Project an der TU ideal. Plugins lassen sich sehr einfach anfügen und durch die riesige Vielfalt von bereits bestehenden Plugins ist auch die Adaption von Plugins möglich bzw. zu empfehlen, denn warum sollte nicht bereits funktionierender Code verwendet werden?\\
       
   316 The importance of connecting the ML-world with the world of user interfaces has been is discussed in Sect.\ref{ml-users}. jEdit follows these lines, it is an open-source, Java-based text editor that works on Windows, Mac OS X, and Linux. A big advantage of jEdit is, that there is a very good and also simple way to use and write a Plugin. There are a lot of useful and powerful Plugins available in the net and it is also possible to use a existing Plugin as part of a new one. Because of this facts, jEdit is very suitable for a project like Isabelle and also for the Isac-project at TU-Graz. \\\\
       
   317 Each jEdit-Plugin basically consists of source files, written in Java or Scala, XML-files and property files. The XML-Files are important for the administration of a Plugin and provides information like the name, author, ... of the Plugin. They are also containing small pieces of BeanShell code which is executed upon a user request. (Like pressing the 'start plugin' button.) So the XML-files provide the “glue” between user input and specific Plugin routines located in the source files. As you see, this files are used as interface between the Plugin and the jEdit engine itself.\\
       
   318 Based on the jEdit API, you are allowed to design your code quit freely and don't have to use a prescribed way to implement your ideas.    
       
   319 To get more information about the jEdit infrastructure see: http://jedit.org/users-guide/plugin-intro
       
   320 \\\\
       
   321 %isabell plugin beschreiben!!!!!!!!
       
   322 The Isabelle-team also follow use this Plugin-structure. In the next paragraph the involved files will be described. The jEdit-Isabelle-Plugin consists of:
       
   323 \begin{itemize}
       
   324 \item 14 Scala-source-files
       
   325 \item three XML-files
       
   326 \item one property file
       
   327 \end{itemize}
       
   328 %Das vom Isabelle-Team erstellte jEdit-Plugin folgt natürlich auch dem oben erklärten Muster. Es wird nun genauer auf dieses Plugin eingegangen. The plugin consits of 14 scala-source-files, three xml-files and one property-file. 
       
   329 The property-file \textit{Isabelle.props} contains general informations about the Isabelle-Plugin and the needed dependencies between Isabelle and the other used Plugins like sidekick. \\
       
   330 The XML-file \textit{dockables.xml} is used to create the needed dock-able windows which are important to set up the GUI of the Plugin.\\
       
   331 In the file \textit{actions.xml}, the dockable windows are added to the window-manager \textit{wm} and there is also some Beanshell-code to activate the Isabelle-GUI.\\
       
   332 The last XML-file is \textit{services.xml} and is used to create instances of needed jEdit-Plugins.\\
       
   333 This four files are located in the folder \textit{plugin}.\\\\
       
   334 The more interesting files, the scala-files of the Plugin, can be found in the 'src/jedit'-directory. In this directory you can find the file \textit{Dummy.java} which is a dummy class and is simply used to make javadoc work. Just forget about this file. Also there is a folder/package \textit{jedit} which contains all Scala-source-files. Now it is time to take a closer look on the source-files: \\
       
   335 The file \textit{plugin.scala} is the main-file of the Isabelle-Plugin and there are two important parts. First the \textit{Isabelle object}. This object contains data like name and path and also few basic functions. The second part is the \textit{class Plugin} which is derived from EBPlugin. Here the basic methods \textit{handleMessage}, \textit{start} and \textit{stop} are implemented. Each jEdit-Plugin should have this methods because they are very important for the handling of the Plugin! \\
       
   336 jEdit and also the Isabelle Plugin work with dock-able windows. This means that you can move around each single window and dock it somewhere on the screen. So it is possible to individualize the jEdit-GUI. To support this, the file \textit{dockable.scala} is needed. The file \textit{output-dockable.scala} is derived from \textit{dockable.scala} and is used to print the result/output in a dock-able window. The same thing with \textit{protocol-dockable.scala} and \textit{raw-output-dockable.scala}.\\
       
   337 The next interesting file is \textit{scala-console.scala} with the main-class Scala-Console. This class is used to expand the Console-Plugin in a way, that it is possible to interpret Scala-code with a Shell inside of jEdit.\\ 
       
   338 The file \textit{isabelle-sidekick.scala} is related to the file \textit{scala-console.scala} because it is also used to adapt the Plugin Sidekick for Isabelle.\\
       
   339 The files \textit{document-model.scala} and \textit{document-view.scala1} are used to connect the jEdit-buffer/the text-area to Isabelle. Both classes offer, upon others, methods to activate and deactivate this features.\\
       
   340 There also some other source-files but they aren’t discussed here, because the main goal of this paragraph is to give a basic idea how a jEdit-Plugin should be set up and the remaining files are not as important for the Isabelle-Plugin-structure:
       
   341 \begin{itemize}
       
   342 \item $html_panel.scala$
       
   343 \item $isabelle_encoding.scala$
       
   344 \item $isabelle_hyperlinks.scala$
       
   345 \item $isabelle_options.scala$
       
   346 \item $isabelle_token_maker.scala$
       
   347 \item $isabelle_hyperlinks.scala$
       
   348 \end{itemize}
       
   349 
       
   350 
       
   351 %  Like each other jEdit-Plugin also this 
       
   352 
       
   353 %Das Konzept des frei wählbaren Designs ist am Beginn villeicht etwas schwierig umzusetzten, da es leichter ist, sich irgendwo anzulehnen bzw. ein bereits bestehendes sowie funktionierendes Konzept zu übernehmen. So wurden auch die ersten Schritte an der TU gemacht. Zu diesem Zweck wurde das von den Entwicklern von jEdit zur Verfügung gestellte plugin 'QuickNotepad' übernommen und in Scala übersetzt. Obwohl Scala eng mit Java verknüpft ist, war doch einiges an 'rewritting' notwendig bis das Scala-plugin lauffähig wurde. Die benötigten XML-files konnten dazu nahezu unberührt gelassen werden.\\
   151 
   354 
   152 \subsection{Details of NetBeans projects}\label{netbeans}
   355 \subsection{Details of NetBeans projects}\label{netbeans}
   153      Scala + Java: html project files
   356 %     Scala + Java: html project files
       
   357 As described in the last paragraph, jEdit is a open-source-project. The jEdit-developers use a NetBeans-project to produce the source-code and so it is beneficial to use a NetBeans project too, because there is a quite good documentation about setting up a NetBeans-project with the jEdit-source. See http://wiki.netbeans.org/NetbeansedJEdit for further information.\\\\
       
   358 If you want to set up a new jEdit-Plugin-project you have to attend that you have to create some source-files and that there must be a connection to the jEdit-source because you will need to exchange data with the jEdit engine. This could probably look like: \textit{jEdit.getProperty("options.isabelle.isabelle")}\\
       
   359 As shown above, the jEdit-source is needed to compile and build your Plugin. There are two ways to organize your project:
       
   360 \begin{itemize}
       
   361 \item with jEdit source code - two projects in one
       
   362 \item with jedit.jar library
       
   363 \end{itemize}
       
   364 \subsubsection{Plugin with jEdit-source}
       
   365 It is a good way to download the jEdit source as Netbeans project because then it is possible to add another subproject to the existing jEdit-NetBeans-project. As you see it is also possible to mix Scala and Java. A big advantage is, that debugging will now work really fine. If you want to set up a project like this, you should complete the following steps.
       
   366 \begin{enumerate}
       
   367 \item {Create a new NetBeans-project for your Plugin like \textit{example-plugin}. This will probably be a Scala-Project.}
       
   368 \item Download (and try out) the \textit{jEdit-NetBeans-project}
       
   369 \item at project \textit{example-plugin}: \textit{Project-browser} $\rightarrow$ Right-click at \textit{Libraries} $\rightarrow$ \textit{add Project...} and then choose the \textit{jEdit-NetBeans-project}.
       
   370 \item at project \textit{example-plugin}: \textit{Project-browser} $\rightarrow$ Right-click at project-name-label $\rightarrow$ \textit{Properties} $\rightarrow$ \textit{Run} $\rightarrow$ \textit{Main Class:} org.gjt.sp.jedit.jEdit
       
   371 \item compile and run
       
   372 \end{enumerate}
       
   373 
       
   374 \subsubsection{Plugin with jedit.jar}
       
   375 It is also possible to use the \textit{jedit.jar} file. This file is already included in \$ISABELLE-HOME/contrib/jedit-4.3.2. Now you just have to follow this steps:
       
   376 \begin{enumerate}
       
   377 \item {Create a new NetBeans-project for your Plugin like \textit{example-plugin}. This will probably be a Scala-Project.}
       
   378 \item at project \textit{example-plugin}: \textit{Project-browser} $\rightarrow$ Right-click at \textit{Libraries} $\rightarrow$ \textit{add JAR/Folder...} and then choose the \textit{jedit.jar} file.
       
   379 \item at project \textit{example-plugin}: \textit{Project-browser} $\rightarrow$ Right-click at project-name-label $\rightarrow$ \textit{Properties} $\rightarrow$ \textit{Run} $\rightarrow$ \textit{Main Class:} org.gjt.sp.jedit.jEdit
       
   380 \item compile and run
       
   381 \end{enumerate}
       
   382 This are two different ways to get started. It is difficult to say what is better because both versions have advantages. Now it is time to start coding your own Plugin but there are still a few things to think about. Remember, that a Plugin consists of source-, XML- and property-files. On default, NetBeans will just pack the source-files in the \textit{example-plugin.jar}-package. So you have to add a copy/move-routine in the \textit{build.xml} file of your NetBeans-project to get a complemented package.
       
   383 \begin{itemize}
       
   384 \item $\langle target name="-pre-jar"\rangle$
       
   385 \item $	\langle copy $file="plugin/services.xml" todir="\${build.classes.dir}" $/\rangle$
       
   386 \item $	\langle copy $file="plugin/dockables.xml" todir="\${build.classes.dir}" $/\rangle$
       
   387 \item $	\langle copy $file="plugin/actions.xml" todir="\${build.classes.dir}" $/\rangle$	
       
   388 \item $	\langle copy $file="plugin/Isabelle.props" todir="\${build.classes.dir}" $/\rangle$
       
   389 \item $	\langle /target\rangle$
       
   390 \end{itemize}
       
   391 %* kurze aufzählung der xml-netbeans-files + erklärung\\
       
   392 \subsubsection{NetBeans project files}
       
   393 As you see in the paragraph above, it is also important to have basic knowledge about NetBeans, the project structure and how to change the operational sequences. A typical NetBeans-project consist of the source- and library-files and administrative XML- and property-files. In this paragraph the administrative part of the project is of note. The most important file is \textit{build.xml}. This file can be found in the project directory. There is also a folder \textit{nbproject} which contains the remaining XML- and property-files and also a folder \textit{private}, where individual user informations about the project is stored. The files in this \textit{private} folder are not important to describe (and they should not be pushed on the repository!).\\
       
   394 A build-file like \textit{build.xml} contains one project and at least one (default) target. Targets contain task elements. Each task element of the build-file can have an id attribute and can later be referred to by the value supplied to this. So the id has to be unique. Such targets can be "run", "debug", "build", ... and can have dependencies to other targets. Tasks define what should happen, if a target is executed. So like in the example above, the target is \textit{pre-jar}, that means that this things will happen before the jar-package is packed. The tasks of this target are copying some files into the package.\\
       
   395 The files inside the \textit{nbproject}-folder are not so important because some of it are generated from \textit{build.xml} and changes in this files are useless. Just the file project.properties is really interesting because this file gives a nice and tight overview about the project settings.
   154 
   396 
   155 \subsection{Use interfaces between Java and Scala}\label{java-scala}
   397 \subsection{Use interfaces between Java and Scala}\label{java-scala}
   156      how are data exchanged between Scala and Java ...
   398 %     how are data exchanged between Scala and Java ...
   157 
   399 jEdit is completely written in Java and the required plugin(s) for Isac will be coded in Scala - so there must be ways to exchange data between Java and Scala. One way is to connect this two worlds with the in 4.2 described XML-files. Here you need to use a third type of code to get an interface between Java and Scala code. But there is also a way to get a direct connection.\\
       
   400 This link should be shown on the graphic-library \textit{Swing}. In both languages it is possible to use Swing which provides a lot of different shapes and useful functionality. So there is a Java-Swing and also a Scala-Swing-library. Now it is interesting to examine the connection between this two libraries.\\
       
   401 In Scala a direct use of Java-Libs (like Java-Swing) is possible. So if you are Java-Programmer and want to use Java-Swing in Scala, you can simply type \textit{import javax.swing.JButton} to work with a Java-button. But you can also use the Scala-equivalent \textit{scala.swing.Button}. This two button-types will provide nearly the same functionality.\\So what is the idea of creating a nearly similar library a second time? Why have the Scala-developers done such extra work? The answer is, that they have tried to improve and simplify the usage of the Swing-library(and many other libs too!). So big parts of this Scala-Libraries are just Wrapper-objects, Wrapper-Classes and Wrapper-Methods of already existing parts in Java-Libraries. Needless to say that they also added new useful shapes and functionality.\\
       
   402 But there is one important question left: Is it possible to mix Scala- and Java-objects? And yes, it is possible. There is a really easy way to convert a Scala-object to the Java-equivalent:
       
   403 \begin{enumerate}
       
   404 \item \textit{import javax.swing.JButton}
       
   405 \item \textit{import scala.swing.Button}
       
   406 \item \textit{var b: scala.swing.Button}
       
   407 \item \textit{var jb: javax.swing.JButton}
       
   408 \item \textit{jb = b.peer}
       
   409 \end{enumerate}
       
   410 As the example above illustrates, a conversion of Scala- to Java-objects is possible. It looks easy but also a little bit useless. Why should you need this? Just imagine that there is a Plugin written in Scala and one coded in Java. With this connection between Scala and Java, it would be easy to connect this two Plugins! 
       
   411 %Diesen direkten Zusammenhang zwischen Java und Scala soll anhand der Grafik-Bibliotheken Swing. Beide Sprachen stellen diese Grafik-Bibliotheken zur Verfügung (und darin auch eigene Shapes und Funktionalität). Es ist jedoch möglich, Java-Bibliotheken, wie eben auch Java-Swing in Scala zu verwenden. Ein JButton kann zum Beispiel mittels \textit{import javax.swing.JButton} eingebunden und damit sofort auch verwendet werden. Auch Scala stellt in seiner Swing-Bibliothek zur Verfügung: \textit{scala.swing.Button}. Es wird nahezu die selbe Funktionalität angeboten und teilweise die Erzeugung bzw. Verwendung vereinfacht(???). Man kann sich nun fragen, warum sich die Scala-Entwickler einerseit die Mühe gemacht haben die Verwendung Java-Swing, wie in Java selbst, möglich zu machen und andererseits mit Scala-Swing eine nahezu idente Alternative geschaffen haben. Die Antwort darauf zeigt wie der objektorientierte Teil von Scala in vielen Bereichen aufgebaut wurden. Es wurde kein neues Konzept für diese Grafikklassen entworfen sondern Wrapper-Objekte/Methoden/Klassen erstellt, die das Arbeiten mit diesen Grafikkomponenten erleichtern soll. Ein Letztes Problem bleibt noch: Es ist zwar sehr einfach ein Java-Swing-Objekt an einen Scala-Swing-Container (zb. Frame) anzubinden, da eine Konvertierung von Java-Komponente in ein Scala-Äquivalent ist problemlos möglich. ...
       
   412 http://www.scala-lang.org/api/current/scala/swing/Button.html\\
       
   413 http://download.oracle.com/javase/1.4.2/docs/api/javax/swing/JButton.html
   158 
   414 
   159 \section{Conclusion and future work}
   415 \section{Conclusion and future work}
   160 
   416 
   161 
   417 
   162 \bibliography{CTP-userinterfaces}
   418 \bibliography{CTP-userinterfaces}