1.1 --- a/doc-src/isac/CTP-userinterfaces.tex	Mon Jan 10 10:19:10 2011 +0100
     1.2 +++ b/doc-src/isac/CTP-userinterfaces.tex	Mon Jan 10 10:31:29 2011 +0100
     1.3 @@ -9,8 +9,8 @@
     1.4  \def\sisac{{\footnotesize${\cal I}\mkern-2mu{\cal S}\mkern-5mu{\cal AC}$}}
     1.5  \def\Problem{ {\tt Problem }}
     1.6  
     1.7 -\title{Upcoming Userinterfaces for Computer Theorem Provers.\\
     1.8 -	The case of Isabelle
     1.9 +\title{Userinterfaces for Computer Theorem Provers.\\
    1.10 +	Contributions to Isabelle
    1.11  }
    1.12  
    1.13  \author{G. Schafhauser, A. Schulhofer, M. Steger\\
    1.14 @@ -68,7 +68,7 @@
    1.15  Coq supports a functional programming language.
    1.16  (http://coq.inria.fr/a-short-introduction-to-coq)
    1.17  \subsubsection{Isabelle}
    1.18 -Isabelle is an interactive theorem proving framework for high-level natural deduction proofs, written in Standard ML. 
    1.19 +Isabelle is an interactive theorem proving framework for high-level natural deduction proofs \cite{Paulson:Isa94}, written in Standard ML. 
    1.20  Isabelle is developed at University of Cambridge (Larry Paulson), Technische Universität München (Tobias Nipkow) 
    1.21  and Université Paris-Sud (Makarius Wenzel).
    1.22  The most widespread instance of Isabelle nowadays is Isabelle/HOL, providing a higher-order logic theorem proving environment.
    1.23 @@ -107,7 +107,7 @@
    1.24  \begin{figure}[htbp]
    1.25  \centering
    1.26  %\includegraphics[bb=0 0 10 10]{coqide.png}
    1.27 -\includegraphics[scale=0.25]{coqide.png}
    1.28 +\includegraphics[scale=0.25]{fig/coqide}
    1.29  \caption{CoqIDE main screen}
    1.30  \end{figure}
    1.31  
    1.32 @@ -128,7 +128,7 @@
    1.33  (http://proofgeneral.inf.ed.ac.uk/fileshow.php?file=releases%2FProofGeneral%2Fisar%2FREADME)
    1.34  \begin{figure}[htbp]
    1.35  \centering
    1.36 -\includegraphics[scale=0.5]{pgisabelle.png}
    1.37 +\includegraphics[scale=0.5]{fig/pgisabelle}
    1.38  \caption{Proof General for Isabelle}%
    1.39  \end{figure}
    1.40  \subsubsection{Isabelle/Jedit}
    1.41 @@ -254,23 +254,29 @@
    1.42  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. \\
    1.43  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.\\
    1.44  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.\\
    1.45 -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.  \\
    1.46 -The main reasons are:\\
    1.47 +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.
    1.48 +The main reasons are:
    1.49  \begin{enumerate}
    1.50 -\item quick exhaustion of virtual address space\\
    1.51 -\item locking mechanisms often lack suitable contention managers\\
    1.52 +\item quick exhaustion of virtual address space
    1.53 +\item locking mechanisms often lack suitable contention managers
    1.54  \end{enumerate}
    1.55  %[IoC]
    1.56 -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.\\
    1.57 -Concurrent processes are usually implemented by using a thread-based or an event-based strategy. 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.\\
    1.58 -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].
    1.59 -Supports blocking operations and can be executed on multicore processors in parallel.\\
    1.60 -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.\\
    1.61 -The implementation of 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. \\
    1.62 -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.\\
    1.63 +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.
    1.64 +\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.
    1.65 +
    1.66 +\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].
    1.67 +Supports blocking operations and can be executed on multicore processors in parallel.
    1.68 +
    1.69 +\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.
    1.70 +
    1.71 +\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.
    1.72 +
    1.73 +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.
    1.74 +
    1.75  receive:         def receive[R](f: PartialFunction[Any, R]): R
    1.76  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]. \\
    1.77 -react:          def react(f: PartialFunction[Any, Unit]): Nothing
    1.78 +react:          
    1.79 +$$\mathit{def}\;\mathit{react}(f: \mathit{PartialFunction}[Any, Unit]): \mathit{Nothing}$$
    1.80  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]. \\
    1.81  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. \\
    1.82  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.\\
    1.83 @@ -307,7 +313,7 @@
    1.84  \subsection{Add a plug-in to jEdit}\label{plugin}
    1.85      % file structure, copied from example project ...
    1.86  %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?\\
    1.87 -jEdit 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. \\\\
    1.88 +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. \\\\
    1.89  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.\\
    1.90  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.    
    1.91  To get more information about the jEdit infrastructure see: http://jedit.org/users-guide/plugin-intro