In this paper, we present Famke. It is a library for Clean that enables the creation and management of independent distributed processes (written in Clean) on a network of computers. The main feature of Famke is that values of any type, i.e. data and code, can be communicated between independent processes in a type safe way. Famke uses Clean's dynamic types and its dynamic linker to extend running applications with new code (plug-ins) that, if its type matches the types used in the application, are guaranteed to fit. Clean no longer offers any support for concurrent evaluation, but fortunately, we can realize threads, signalling and exception handling by using first class continuations without the need for additional run-time support. We have made an interactive shell on top of Famke with which the user can manipulate processes interactively. The shell uses a functional-style command language and it type checks the command line before performing it. Preemptive scheduling is done by the underlying operating system (currently Microsoft Windows) but cooperative scheduling is done by Famke. Famke has been made in such a way that it could very well serve as the kernel of a stand-alone operating system entirely written in a pure functional language.

Key words:This paper presents a case study on the use of formal methods in specificationbased, black-box testing of a smart card applet. The system under test is a simple electronic purse application running on a Java Card platform. The specification of the applet is given as a Statechart model, and transformed into a functional form to serve as the input for the on-the-fly test generation, -execution, and -analysis tool GAST. We show that automated, formal, specification-based testing of smart card applets is of high value, and that errors can be detected using this model-based testing. model-based testing; smart cards; Java Card; automatic test generation; executable specification.

Invertible programming occurs in the area of data conversion where it is required that the conversion in one direction is the inverse of the other. For that purpose, we introduce bidirectional arrows (biarrows). The bi-arrow class is an extension of Haskell's arrow class with an extra combinator that changes the direction of computation.The advantage of the use of bi-arrows for invertible programming is the preservation of invertibility properties using the biarrow combinators. Programming with bi-arrows in a polytypic or generic way exploits this the most. Besides bidirectional polytypic examples, including invertible serialization, we give the definition of a monadic bi-arrow transformer, which we use to construct a bidirectional parser/pretty printer.

Programming GUIs with conventional GUI APIs is notori ously tedious. In these notes we present the GEC toolkit in which the programmer can create user interfaces without any knowledge of lowlevel I/O handling. Instead, he works with Graphical Editor Components (GEC). A GEC is an interactive component that is automatically derived from an arbitrary monomorphic data type, including higher order types. It contains a value of that data type, visualizes it, and allows the user to manipulate it in a type-safe way. The toolkit has a library of data types that represent standard GUI elements such as buttons, text fields, and so on. As a consequence, the programmer works with data types that model the interactive system that he is interested in. Programs are con structed as a collection of communicating GECs. This communication can be arranged in an ad-hoc way, or in a disciplined way, using a combinator library based on arrows. GECs are suitable for rapid prototyping of real world applications, for teaching and for debugging. These notes focus on the use of the GEC toolkit for functional programmers, only briefly explaining its inner workings and underlying principles.

Abstract. We present a new shell that provides the full basic functionality of a strongly typed lazy functional language, including overloading. The shell can be used for manipulating files, applications, data and processes at the command line. The shell does type checking and only executes well-typed expressions. Files are typed, and applications are simply files with a function type. The shell executes a command line by combining existing code of functions on disk. We use the hybrid static/dynamic type system of Clean to do type checking/inference. Its dynamic linker is used to store and retrieve any expression (both data and code) with its type on disk. Our shell combines the advantages of interpreters (direct response) and compilers (statically typed, fast code). Applications (compiled functions) can be used, in a type safe way, in the shell, and functions defined in the shell can be used by any compiled application.