3 Using a Prototype

We have used PICT [PT97], an experimental programming language based on the polyadic mini $\pi$-calculus, as an executable specification language to model objects, synchronization abstractions, and interceptors. The main goal of this work was to test if the $\pi$-calculus serves as a good formal foundation to define components and glue. It turned out that the language PICT was a good choice in first place, but as the modelled abstractions became more and more sophisticated, we had to realize that PICT was too restrictive and not appropriate any more for our needs. Therefore, we decided to start with an implementation of our own $\pi$-calculus based programming language. The domain of this language is primarily component scripting, but it will also be used to evaluate our component-oriented higher level abstractions.

There are several reasons why we started implementing our own language. First of all, we need our own platform in which we are able to control the mapping of language constructs to the underlying calculus and more important to experiment with different type systems. PICT is not an open language and we do not have any hooks which can be used to change the default semantics of the language. But it is crucial for our work to have facilities available that allow us to experiment with new abstractions.

Second, PICT can be seen more or less as a general purpose programming language. But what we need is a language which can be used to glue components supporting the right kind of formal semantics. For this reason our composition language will provide gluing and scripting mechanisms based on the $\pi$-calculus.

We started with a dynamically typed language design. Dynamic typing is one of the main features of modern scripting languages [Ous97]. This approach should give us more freedom to compose arbitrary components, but requires more effort in the runtime system. It is not yet clear what is the right type system, but we hope that experimenting with several type systems in PICCOLA will lead to a sound type system suitable for gluing components.

Now, what is the right kind of language or system for a prototype language environment? Should we use a general purpose language or not? Should we use an interpreter or compiler for both the implementation of our system and its execution? Can we use the same system for compilation and execution of programs? We could ask hundreds of these questions.

We have chosen Java as implementation platform. We feel that Java is the right system for prototyping. The Java language is platform neutral and we must not worry about platform specific problems. We can use Java for both compilation and execution of programs. Implementing our prototype language in Java allows us to easily integrate Java objects as rough component abstractions in our system. We have a rich set of predefined classes which makes it easier to implement our language. And the most crucial property of the Java system is that multithreading as well as real distributed execution is available by default.

The current prototype of JPICT, where a first version of PICCOLA is used as the composition language, consists of three parts: scanning and parsing of PICCOLA, translation to a core language, and a runtime system for the core language.

For the scanning and parsing part we have used an object-oriented technique. The use of tools like Lex and Yacc for Java do not seem to be appropriate for us. If we have to change a part of the language, then it is more difficult to manage all necessary modification when using these tools. In our object-oriented approach we assign each building block of the language a corresponding class. Currently, we have implemented the lexer and parser in one piece, but we are experimenting with a new approach which allows us to add new language constructs to the compiler more or less at runtime. We call this approach modular compiler construction. This approach uses metaclasses to configure the compilation. Unfortunately, we currently do not have a good support for this in Java.

The core code consists of the basic $\pi$-calculus constructs: sending process, receiving process, create a new channel, and parallel composition of processes. Each of these constructs is implemented in one class. The translation phase maps higher level abstractions like assignment, function definition, and function calls to the corresponding core constructs.

The runtime system heavily uses threads. A $\pi$-process is simply mapped to a Java-thread. The synchronization of threads is achieved by calling the corresponding put and get methods of the channels used in the thread communication.

Unfortunately, a 1:1 mapping of $\pi$-processes to a Java thread is not the best solution. It turned out that even for simple programs with some objects more than 100 threads were created. It is not yet clear, what will be the optimal number of threads, but as more threads are active, the execution speed dramatically goes down due to the thread specific overhead.

Fortunately, our first results show that our approach works. Even with the penalties mentioned we got results within days. Implementing the first version of the system took us only two weeks. The first version implemented only the core language set, but is was a solid base for further extensions. A next version was enriched with higher level abstraction like assignment and functions. Additionally, we have implemented a first version of channel interceptors [SL97].

We still have some problems with our implementation. Especially the chosen mapping of a $\pi$-process to a Java thread has to be changed in future versions. But the results are promising and we plan to extend our system with additional features like reflection support and a powerful object model. Furthermore, we will also add a visual development environment as a composition workbench.