We describe the design and current status of our effort to implement the programming model of nested data parallelism into the Glasgow Haskell Compiler. We extended the original programmingmodel and its implementation, both of which were first popularised by the NESL language, in terms of expressiveness as well as efficiency. Our current aim is to provide a convenient programming environment for SMP parallelism, and especially multicore architectures. Preliminary benchmarks show that we are, at least for some programs, able to achieve good absolute performance and excellent speedups.

. We present our experiences using a purely functional language, Haskell, in what has been traditionally the realm of low-level languages: robot control. Frob (Functional Robotics) is a domain-specific language embedded in Haskell for robot control. Frob is based on Functional Reactive Programming (FRP), as initially developed for Fran, a language of reactive animations. Frob presents the interaction between a robot and its stimuli, both onboard sensors and messages from other agents, in a purely functional manner. This serves as a basis for composable high level abstractions supporting complex control regimens in a concise and reusable manner. 1 Introduction Robotics is a an excellent problem domain to demonstrate the power and flexibility of declarative programming languages. Among the more interesting problem areas in this domain are control systems, constraint solving, reactive programming, sensor fusion, and real-time control. We have developed Frob (for Functional Robotics) as ...

Functional Reactive Programming, or FRP, is a general framework for programming hybrid systems in a high-level, declarative manner. The key ideas in FRP are its notions of behaviors and events. Behaviors are time-varying, reactive values, while events are time-ordered sequences of discrete-time event occurrences. FRP is the essence of Fran, a domainspeci c language embedded in Haskell for programming reactive animations, but FRP is now also being used in vision, robotics and other control systems applications. In this paper we explore the formal semantics of FRP and how it relates to an implementation based on streams that represent (and therefore only approximate) continuous behaviors. We show that, in the limit as the sampling interval goes to zero, the implementation is faithful to the formal, continuous semantics, but only when certain constraints on behaviors are observed. We explore the nature of these constraints, which vary amongst the FRP primitives. Our results show both the power and limitations of this approach to language design and implementation. As an example of a limitation, we show that streams are incapable of representing instantaneous predicate events over behaviors. 1.

Abstract not found

Some modern superscalar microprocessors provide only imprecise exceptions. That is, they do not guarantee to report the same exception that would be encountered by a straightforward sequential execution of the program. In exchange, they offer increased performance or decreased chip area (which amount to much the same thing). This performance/precision tradeoff has not so far been much explored at the programming language level. In this paper we propose a design for imprecise exceptions in the lazy functional programming language Haskell. We discuss several designs, and conclude that imprecision is essential if the language is still to enjoy its current rich algebra of transformations. We sketch a precise semantics for the language extended with exceptions. The paper shows how to extend Haskell with exceptions without crippling the language or its compilers. We do not yet have enough experience of using the new mechanism to know whether it strikes an appropriate balance between expressiveness and pwrformance.

Abstract. Curry is a multi-paradigm declarative language covering functional, logic, and concurrent programming paradigms. Curry’s operational semantics is based on lazy reduction of expressions extended by a possibly non-deterministic binding of free variables occurring in expressions. Moreover, constraints can be executed concurrently which provides for concurrent computation threads that are synchronized on logical variables. In this paper, we extend Curry’s basic computational model by a few primitives to support distributed applications where a dynamically changing number of different program units must be coordinated. We develop these primitives as a special case of the existing basic model so that the new primitives interact smoothly with the existing features for search and concurrent computations. Moreover, programs with local concurrency can be easily transformed into distributed applications. This supports a simple development of distributed systems that are executable on local networks as well as on the Internet. In particular, sending partially instantiated messages containing logical variables is quite useful to implement reply messages. We demonstrate the power of these primitives by various programming examples. 1

Eden is a concurrent declarative language that aims at both the programming of reactive systems and parallel algorithms on distributed memory systems. In this paper, we explain the computation and coordination model of Eden. We show how lazy evaluation in the computation language is fruitfully combined with the coordination language that is specifically designed for multicomputers and that aims at maximum parallelism. The two-level structure of the programming language is reflected in its operational semantics, which is sketched shortly.

This paper proposes to combine two seemingly opposed programming models for building massively concurrent network services: the event-driven model and the multithreaded model. The result is a hybrid design that offers the best of both worlds—the ease of use and expressiveness of threads and the flexibility and performance of events. This paper shows how the hybrid model can be implemented entirely at the application level using concurrency monads in Haskell, which provides type-safe abstractions for both events and threads. This approach simplifies the development of massively concurrent software in a way that scales to real-world network services. The Haskell implementation supports exceptions, symmetrical multiprocessing, software transactional memory, asynchronous I/O mechanisms and application-level network protocol stacks. Experimental results demonstrate that this monad-based approach has good performance: the threads are extremely lightweight (scaling to ten million threads), and the I/O performance compares favorably to that of Linux NPTL. Categories and Subject Descriptors D.1.1 [Programming techniques]:

. Every now and then, a user of the Glasgow Haskell Compiler asks for a feature that requires specialised support from the storage manager. Memo functions, pointer equality, external pointers, nalizers, and weak pointers, are all examples. We take memo functions as our exemplar because they turn out to be the trickiest to support. We present no fewer than four distinct mechanisms that are needed to support memo tables, and that (in various combinations) satisfy a variety of other needs. The resulting set of primitives is undoubtedly powerful and useful. Whether they are too powerful is not yet clear. While the focus of our discussion is on Haskell, there is nothing Haskell-specic about most of the primitives, which could readily be used in other settings. 1 Introduction \Given an arbitrary function f, construct a memoised version of f; that is, construct a new function with the property that it returns exactly the same results as f, but if it is applied a second time to ...

. We describe a process extension to a lazy functional programming system, intended for applications with graphical user interfaces (GUIs). In the extended language, dynamically-created processes communicate by asynchronous message passing. We illustrate the use of the language, including as an extended example a simple board game in which squares are implemented as concurrent processes. We also describe a window manager, itself implemented in the extended functional language. Keywords: functional language, processes, concurrency, window manager, Gofer. 1 Introduction and Motivation Most of the time, elements of a graphical user interface (GUI) operate independently. For example, a menu doesn't interact with the rest of the program until the user selects an option. The user can highlight options, open up further menus or move the menu around the screen, all without doing anything that should concern any other element of the program. Popular languages such as C do not readily lend the...