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 : : ...

. A purely functional file system has been built on top of pure Scheme. It provides persistent structures and massive storage expected of file systems, without explicit side-effects like read and write. The file system becomes an additional, lazy argument to programs that would read from it, and an additional result from functions that would alter it. Functional programming on lazy structures replaces in-place side-effects with a significant storage management problem, handled by conjoining the heap to the file system. A hardware implementation of reference counting is extended out to manage sectors, as well as the primary heap. Backing it is a garbage collector of heap and of disk (i.e. UNIX's fsck), needed only at reboot. CR categories and Subject Descriptors: D.4.2 [Storage Management]: Storage hierarchies; D.1.1 [Applicative (Functional) Programming]; E.2 [Data Storage Representations]: Linked representations; H.0 [Information Systems]. General Term: Design. Additional Key Wor...

Persistent programming languages provide abstract mechanisms which completely describe the storage and retrieval of long term data. In this paper, the Ten15 persistent programming language is reviewed. Ten15 can be categorised as supporting a minimal persistence mechanism and an extremely powerful and expressive type system. Details of using Ten15 to build a general purpose filing system, based on dictionaries, are given. It is concluded that the ability to build a complex and flexible file system depends on two factors: the constructive power of the type system and the flexibility of the minimal persistent store. ############### * Research is sponsored by SERC/UK research grant number 89556293 and with the support of the Procurement Executive Ministry of Defence. 1. Introduction Persistence is the ability for program data to endure longer than the invocation of the program which creates it [2]. It has formed the basis for a large research community which has identified the underly...

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...