The new release of Clean oers a hybrid type system with both static and dynamic typing. Any common static Clean expression can in principle be converted into a dynamic expression (called a "dynamic "), and backwards. The type of the dynamic (an encoding of the original static type) can be checked at run-time via a special pattern match after which the dynamic expression can be evaluated as eciently as usual. Clean furthermore oers "dynamic I/O": any application can read in a dynamic that is stored by some other application. Such a dynamic can contain unevaluated functions (closures) that are unknown in the receiving application. The receiving application therefore has to be extended with these function de nitions. This is not trivial because Clean uses compiled code and is not an interpreted language that uses some byte code. A running Clean application therefore communicates with a dynamic linker that is able to add the missing binary code to the running application. So, dynamics can be used to realize plug-ins and mobile code in a type safe way without loss of eciency in the resulting code. In this paper we explain the implementation of dynamic I/O. Dynamics are written in such a way that internal sharing is preserved when a dynamic is read. Dynamics are read in very lazily in phases: rst its type is checked, and only if the evaluation is demanded, the dynamic expression is reconstructed and the new code is linked in. Dynamics can become quite complicated: they can contain sharing, they can be cyclic, they can even refer to other dynamics, and they may be distributed over a computer network. We have managed to completely hide the internal storage structure for the user by separating the storage of dynamics in system space and user space. For the user a dynamic o...

DataTypes : : : : : : : : : : : : : : : : : : : : : : : : : 40 4.2 PolymorphicDataTypes : : : : : : : : : : : : : : : : : : : : : : : 40 vi 4.3 Existential DataTypes : : : : : : : : : : : : : : : : : : : : : : : : 41 4.4 DynamicTypes : : : : : : : : : : : : : : : : : : : : : : : : : : : : 43 4.5 Dynamic Semantics : : : : : : : : : : : : : : : : : : : : : : : : : : 45 5 A Tiny Programming Language 48 5.1 Tiny Layout Conventions : : : : : : : : : : : : : : : : : : : : : : 48 5.2 Existential Type Variables : : : : : : : : : : : : : : : : : : : : : : 50 5.3 Type Signatures withHoles : : : : : : : : : : : : : : : : : : : : : 50 5.4 PolymorphicAbstractions : : : : : : : : : : : : : : : : : : : : : : 51 5.5 Top-Level Function Signatures : : : : : : : : : : : : : : : : : : : : 53 5.6 AlgebraicDataTypes : : : : : : : : : : : : : : : : : : : : : : : : 54 5.7 Restricted Type Synonyms and Newtype : : : : : : : : : : : : : : 55 5.8 Summary of Type System : : : : : : : : : : : : : : : : : : : : : : 56 5.9 DynamicTypes : : : : : : : : : : : : : : : : : : : : : : : : : : : : 57 6 Systems Programming with Dynamic Types 59 6.1 Error Handling : : : : : : : : : : : : : : : : : : : : : : : : : : : : 59 6.2 Inter-Process Communication : : : : : : : : : : : : : : : : : : : : 62 6.3 A Simple Address Server : : : : : : : : : : : : : : : : : : : : : : : 64 6.4 A Simple File Server : : : : : : : : : : : : : : : : : : : : : : : : : 66 6.5 A Capability System : : : : : : : : : : : : : : : : : : : : : : : : : 69 6.6 Distributed Inter-Process Communication : : : : : : : : : : : : : 75 6.7 A Compiler Interface : : : : : : : : : : : : : : : : : : : : : : : : : 78 6.8 AFunctional Compiler Interface : : : : : : : : : : : : : : : : : : 81 7 Dynamic Overloading 83 7.1 Dynamically Resolved Overloading : : ...

This paper proposes a database manipulation interface for the statically typed, purely functional programming language Haskell. The data model uses surrogates to permit direct update of stored objects, and the basic interface is designed based on the state-transformer approach, so that the interface is referentially transparent. This approach requires all the operations to be executed in a single state-transition sequence and thus tends to make queries more imperative than expected. The proposed approach lessens this burden on query construction, by using versioning. Versions can be "frozen" or locked, and a set of locked versions can be supplied as an argument to query operations. This intraprogram versioning permits on-the-fly dereference during query construction, and allows for straightforward implementation of lazy retrieval in strict state-transition sequences. 1 Introduction Some distinctive features of purely functional programming languages are that their background is declar...

Abstract not found

The original aim of the work that led to this dissertation was to extend an existing, purely functional language with facilities for input/output and modular programming. The language is based on an untyped -calculus, i.e., program execution is defined as program transformation according to a fixed set of reduction rules including fi-reduction. Consistently, the implementation comprises an interactive reduction system which is integrated with a syntax-oriented editor: any sub-expression or program result can be submitted for (stepwise) reduction. There is no distinguished main program, no `global' environment and no explicit static part of the language -- in particular, there is no static type system. It is therefore not clear how to add one of the known solutions for input/output or modular programming to such a programming environment. Furthermore, simply adding features to the language would lead to a complex language design with weakly integrated parts, thus losing much of the appe...