As software becomes more and more complex, it is more and more important to structure it well. Well-structured software is easy to write, easy to debug, and provides a collection of modules that can be re-used to reduce future programming costs. Conventional languages place conceptual limits on the way problems can be modularised. Functional languages push those limits back. In this paper weshow that two features of functional languages in particular, higher-order functions and lazy evaluation, can contribute greatly to modularity. As examples, we manipulate lists and trees, program several numerical algorithms, and implement the alphabeta heuristic (an algorithm from Arti cial Intelligence used in game-playing programs). Since modularity is the key to successful programming, functional languages are vitally important to the real world. 1

Databases and have developed one another for Traditionally, the interface between a programming language and a database has either

machines and implementations : : : : : : : : : : : : : : : : : : : 7 1.4 Optimized implementation : : : : : : : : : : : : : : : : : : : : : : : : : : : 9 1.5 Plan of the report : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 10 2 Semantics-Based Program Analysis 12 2.1 Semantics and program analysis : : : : : : : : : : : : : : : : : : : : : : : : 12 2.2 Abstract interpretation : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 12 2.3 Semantic analysis information : : : : : : : : : : : : : : : : : : : : : : : : : 13 2.4 Instrumented semantics : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 14 2.5 Correctness of analyses : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 15 3 A Lazy Example Language 19 3.1 The lazy language L : : : : : : : : : : : : : : : : : : : : : : : : : : : : : : 19 3.2 The call by name Krivine machine : : : : : : : : : : : : : : : : : : : : : : : 21 3.3 Adding data structures : : : : : : : : : : : : : : : : : : : : : : : ...

The foundations of functional programming languages are examined from both historical and technical perspectives. Their evolution is traced through several critical periods: early work on lambda calculus and combinatory calculus, Lisp, Iswim, FP, ML, and modern functional languages such as Miranda ’ and Haskell. The fundamental premises on which

Abstract not found

The architecture of future high performance computer systems will respond to the possibilities offered by technology and to the increasing demand for attention to issues of programmability. Multithreaded processing element architectures are a promising alternative to RISC architecture and its multiple-instruction-issue extensions such as VLIW, superscalar, and superpipelined architectures. This paper presents an overview of multithreaded computer architectures and the technical issues affecting their prospective evolution. We introduce the basic concepts of multithreaded computer architecture and describe several architectures representative of the design space for multithreaded, parallel computers. We review design issues for multithreaded processing elements intended for use as the node processor of parallel computers for scientific computing. These include the question of choosing an appropriate program execution model, the organization of the processing element to achieve good utilization of major resources, support for fine-grain interprocessor communication and global memory access, compiling machine code for multithreaded processors, and the challenge of implementing virtual memory in large-scale multiprocessor systems.

. This paper presents a polytypic implementation of memo functions that are based on digital search trees. A memo function can be seen as the composition of a tabulation function that creates a memo table and a look-up function that queries the table. We show that tabulation can be derived from look-up by inverse function construction. The type of memo tables is dened by induction on the structure of argument types and is parametric with respect to the result type of memo functions. A memo table for a xed argument type is then a functor and look-up and tabulation are natural isomorphisms. We provide simple polytypic proofs of these properties. 1 Introduction A memo function [11] is like an ordinary function except that it caches previously computed values. If it is applied a second time to a particular argument, it immediately returns the cached result, rather than recomputing it. For storing arguments and results a memo function internally employs an index structure, the ...

This thesis presents and justifies a framework for programming real-time signal processing systems. The framework extends the existing "block-diagram" programming model; it has three components: a very high-level textual language, a visual language, and the dataflow process network model of computation. The dataflow process network model, although widely-used, lacks a formal description, and I provide a semantics for it. The formal work leads into a new form of actor. Having established the semantics of dataflow processes, the functional language Haskell is layered above this model, providing powerful features---notably polymorphism, higher-order functions, and algebraic program transformation---absent in block-diagram systems. A visual equivalent notation for Haskell, Visual Haskell, ensures that this power does not exclude the "intuitive" appeal of visual interfaces; with some intelligent layout and suggestive icons, a Visual Haskell program can be made to look very like a block dia...

This paper reviews and extends an analytical model for the behavior of dataflow graphs with data-dependent control flow. The number of tokens produced or consumed by each actor is given as a symbolic function of the Booleans in the system. Long-term averages can be analyzed to determine consistency of token flow rates. Short-term behavior can be analyzed to construct an annotated schedule, or a static schedule that annotates each firing of an actor with the Boolean conditions under which that firing occurs. Necessary and sufficient conditions for bounded-length schedules, as well as sufficient conditions for determining that a dataflow graph can be scheduled in bounded memory are given. Annotated schedules can be used to generate efficient implementations of the algorithms described by the dataflow graphs. 1. Introduction The principal strength of dataflow graphs is that they do not over-specify an algorithm by imposing unnecessary sequencing constraints between operators. Instead, th...

Although many data-parallel functional languages exist, Lisp, NESL, Paralation Lisp, FX and Parallel EuLisp, few researchers have investigated incorporating data-parallelism with a lazy language. This paper describes data-parallel extensions which have been incorporated into the lazy functional language Haskell. We describe pods, parallel data structures that share many of the characteristics of Haskell arrays---their distinguishing feature however is they are unbounded. We present POD comprehensions, a framework within which communication and parallel operations on PODs can be expressed. The semantics of these extensions is given in terms of translation rules into a core set of primitive parallel operations. Particular attention is given to the non-strict nature of these extensions. Development of the higher order parallel map, fold, and scan is presented, a trio of functions that is widely accepted as being fundamental to a data-parallel paradigm. Ladner classifies a problem as being susceptible to parallel scanning if it is of a fixed size and can be solved by a finite state transducer. We show that by utilising lazy evaluation, Ladners requirements can be relaxed such that the lazy verzion of scan presented here has the potential to scan an infinite POD.