This paper describes, mostly in an informal way, a method for translating formal, model-based specifications, into functional prototypes. Such prototypes can be used to validate software system specifications in the very early stages of the design process. We show how to translate the executable subset of the VDM language into Lazy ML, establishing the translation schemes and requirements needed for an automated translation process. Here we are not concerned with implicit specifications, but indicate, in places, what has to be done in order for such specifications to be automatically translated into a functional program. A small example is presented and, being itself part of a translation system from VDM to LML, gives the reader a good idea of the power of the approach. Keywords: Formal Methods, Formal Specification, Rapid Prototyping, Software Validation, Animation Techniques, Functional Languages. 2 Introduction This article is concerned with the animation of model-based formal spe...

We describe the design and use of monadic I/O in Haskell 1.3, the latest revision of the lazy functional programming language Haskell. Haskell 1.3 standardises the monadic I/O mechanisms now available in many Haskell systems. The new facilities allow fairly sophisticated text-based application programs to be written portably in Haskell. The standard provides implementors with a flexible framework for extending Haskell to incorporate new language features. Apart from the use of monads, the main advances over the previous standard are: character I/O based on handles (analogous to ANSI C file pointers), an error handling mechanism, terminal interrupt handling and a POSIX interface. Apart from a tutorial description of the new facilities we include a worked example: a derived monad for combinator parsing. 1 Introduction Haskell 1.3 improves on previous versions of Haskell [12] by adopting an I/O mechanism based on monads [19]. This paper explains the structure of this monadic I/O mechanis...

In imperative languages I/O is realized through sequences of sideeffecting function applications/ procedure invocations. This seems to be a suitable way of specifying I/O since it coincides with an intuitive understanding of it as sequences of actions. In contrast, functional languages carefully have to avoid side-effects to sustain referential transparency. Many different solutions, such as dialogues, continuations, monads and uniqueness typing have been proposed. The I/O facilities of Sac are based on uniqueness typing. Instead of using an explicit type attribute as in Clean, unique types are introduced as special modules called classes. To provide a syntax as close as possible to that of imperative languages, we propose two new mechanisms to be included on top of classes in Sac: a call-by-reference mechanism and global objects. Although a combination of both mechanisms allows for very imperative-like notations, we can define a purely functional semantics. Thus we combine the advant...

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

Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

We propose a conservative extension of HM(X), a generic constraint-based type inference framework, with existential (a.k.a. abstract) and universal (a.k.a. polymorphic) datatypes. In the first part of the article, which remains abstract of the type and constraint language (i.e. the logic X), we introduce the type system, prove its safety and define a type inference algorithm which computes principal typing judgments. In the second part, we propose a realistic constraint solving algorithm for the case of structural subtyping, which handles the non-standard construct of the constraint language generated by type inference: a form of bounded universal quantification.

OzFun is a functional language that integrates eager and lazy programming. It compiles into the concurrent constraint language Oz. Demand propagation is expressed via logic variables. OzFun syntax extends functional Oz syntax. OzFun offers the entire functional part of the Oz-library whether for eager or lazy programming. OzFun allows incremental input and output and its interface is based on Oz's Emacs and the Oz-Browser. OzFun is dynamically typed. It is a prototypical language useful for teaching. OzFun owns a programming and implementation model which are calculi. The efficiency of eager OzFun programs equals Oz's efficiency and is thus competitive with ML and Haskell. However the performance of lazy OzFun programs is not competitive with Haskell programs: lazy data structures are compiled to high-level Oz data-structures. There is no strictness analyzer available. The following sections outline OzFun's design and implementation 's issues and address our experiences with the Oz pr...

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

Languages with rich type systems are beginning to employ a blend of type inference and type checking, so that the type inference engine is guided by programmer-supplied type annotations. In this paper we show, for the first time, how to combine the virtues of two well-established ideas: unification-based inference, and bidirectional propagation of type annotations. The result is a type system that conservatively extends Hindley-Milner, and yet supports both higher-rank types and impredicativity. Categories and Subject Descriptors D.3.3 [PROGRAMMING