Results 1 - 10
of
31
Tackling the awkward squad: monadic input/output, concurrency, exceptions, and foreign-language calls in Haskell
- Engineering theories of software construction
, 2001
"... Functional programming may be beautiful, but to write real applications we must grapple with awkward real-world issues: input/output, robustness, concurrency, and interfacing to programs written in other languages. These lecture notes give an overview of the techniques that have been developed by th ..."
Abstract
-
Cited by 88 (2 self)
- Add to MetaCart
Functional programming may be beautiful, but to write real applications we must grapple with awkward real-world issues: input/output, robustness, concurrency, and interfacing to programs written in other languages. These lecture notes give an overview of the techniques that have been developed by the Haskell community to address these problems. I introduce various proposed extensions to Haskell along the way, and I offer an operational semantics that explains what these extensions mean. This tutorial was given at the Marktoberdorf Summer School 2000. It will appears in the book “Engineering theories of software construction, Marktoberdorf Summer School 2000”, ed CAR Hoare, M Broy, and R Steinbrueggen, NATO ASI Series, IOS Press, 2001, pp47-96. This version has a few errors corrected compared with the published version. Change summary: Apr 2005: some examples added to Section 5.2.2, to clarifyevaluate. March 2002: substantial revision 1
Transactional Events
, 2008
"... Concurrent programs require high-level abstractions in order to manage complexity and enable compositional reasoning. In this paper, we introduce a novel concurrency abstraction, dubbed transactional events, which combines first-class synchronous message passing events with all-or-nothing transactio ..."
Abstract
-
Cited by 20 (1 self)
- Add to MetaCart
Concurrent programs require high-level abstractions in order to manage complexity and enable compositional reasoning. In this paper, we introduce a novel concurrency abstraction, dubbed transactional events, which combines first-class synchronous message passing events with all-or-nothing transactions. This combination enables simple solutions to interesting problems in concurrent programming. For example, guarded synchronous receive can be implemented as an abstract transactional event, whereas in other languages it requires a non-abstract, non-modular protocol. As another example, three-way rendezvous can be implemented as an abstract transactional event, which is impossible using first-class events alone. Both solutions are easy to code and easy to reason about. The expressive power of transactional events arises from a sequencing combinator whose semantics enforces an all-or-nothing transactional property – either both of the constituent events synchronize in sequence or neither of them synchronizes. This sequencing combinator, along with a non-deterministic choice combinator, gives transactional events the compositional structure of a monad-with-plus. We provide a formal semantics for transactional events and give a detailed account of an implementation.
Error Scope on a Computational Grid: Theory and Practice
- In Proceedings of the Eleventh IEEE Symposium on High Performance Distributed Computing
, 2002
"... Error propagation is a central problem in grid computing. We re-learned this while adding a Java feature to the Condor computational grid. Our initial experience with the system was negative, due to the large number of new ways in which the system could fail. To reason about this problem, we develop ..."
Abstract
-
Cited by 16 (3 self)
- Add to MetaCart
Error propagation is a central problem in grid computing. We re-learned this while adding a Java feature to the Condor computational grid. Our initial experience with the system was negative, due to the large number of new ways in which the system could fail. To reason about this problem, we developed a theory of error propagation. Central to our theory is the concept of an error's scope, defined as the portion of a system that it invalidates. With this theory in hand, we recognized that the expanded system did not properly consider the scope of errors it discovered. We modified the system according to our theory, and succeeded in making it a more robust platform for distributed computing.
Compiling Exceptions Correctly
- In Proceedings of the 7th International Conference on Mathematics of Program Construction
, 2004
"... Exceptions are an important feature of modern programming languages, but their compilation has traditionally been viewed as an advanced topic. In this article we show that the basic method of compiling exceptions using stack unwinding can be explained and verified both simply and precisely, usin ..."
Abstract
-
Cited by 14 (4 self)
- Add to MetaCart
Exceptions are an important feature of modern programming languages, but their compilation has traditionally been viewed as an advanced topic. In this article we show that the basic method of compiling exceptions using stack unwinding can be explained and verified both simply and precisely, using elementary functional programming techniques.
Optimistic Evaluation: An Adaptive Evaluation Strategy for Non-Strict Programs
- In ICFP ’03: Proceedings of the eighth ACM SIGPLAN international conference on Functional programming
, 2003
"... Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this obs ..."
Abstract
-
Cited by 14 (2 self)
- Add to MetaCart
Lazy programs are beautiful, but they are slow because they build many thunks. Simple measurements show that most of these thunks are unnecessary: they are in fact always evaluated, or are always cheap. In this paper we describe Optimistic Evaluation --- an evaluation strategy that exploits this observation. Optimistic Evaluation complements compile-time analyses with run-time experiments: it evaluates a thunk speculatively, but has an abortion mechanism to back out if it makes a bad choice. A run-time adaption mechanism records expressions found to be unsuitable for speculative evaluation, and arranges for them to be evaluated more lazily in the future.
A Higher-Level Language for Hardware Synthesis
- Proc. of Correct Hardware Design and Veri Methods (CHARME
, 2001
"... the style of ML which combines imperative, concurrent and functional programming. Synchronous channels allow communication between parallel threads and π-calculus style channel passing is provided. SAFL+ is designed for hardware description and synthesis; a silicon compiler, translating SAFL+ into R ..."
Abstract
-
Cited by 11 (3 self)
- Add to MetaCart
the style of ML which combines imperative, concurrent and functional programming. Synchronous channels allow communication between parallel threads and π-calculus style channel passing is provided. SAFL+ is designed for hardware description and synthesis; a silicon compiler, translating SAFL+ into RTL-Verilog, has been implemented. By parameterising functions over both data and channels the SAFL+ fun declaration becomes a powerful abstraction mechanism unifying a range of structuring techniques treated separately by existing HDLs. We show how SAFL+ is implemented at the circuit level and define the language formally by means of an operational semantics. 1
Towards a Strongly Typed Functional Operating System
- The 14th International Workshop on the Implementation of Functional Languages, IFL'02, Selected Papers, volume 2670 of LNCS
, 2002
"... In this paper, we present Famke. It is a library for Clean that enables the creation and management of independent distributed processes (written in Clean) on a network of computers. The main feature of Famke is that values of any type, i.e. data and code, can be communicated between independent ..."
Abstract
-
Cited by 10 (4 self)
- Add to MetaCart
In this paper, we present Famke. It is a library for Clean that enables the creation and management of independent distributed processes (written in Clean) on a network of computers. The main feature of Famke is that values of any type, i.e. data and code, can be communicated between independent processes in a type safe way. Famke uses Clean's dynamic types and its dynamic linker to extend running applications with new code (plug-ins) that, if its type matches the types used in the application, are guaranteed to fit. Clean no longer o#ers any support for concurrent evaluation, but fortunately, we can realize threads, signalling and exception handling by using first class continuations without the need for additional run-time support. We have made an interactive shell on top of Famke with which the user can manipulate processes interactively.
Writing High-Performance Server Applications in Haskell Case Study: A Haskell Web Server
- In Haskell Workshop
, 2000
"... Server applications, and in particular networkbased server applications, place a unique combination of demands on a programming language: lightweight concurrency and high I/O throughput are both important. This paper describes a prototype web server written in Concurrent Haskell, and presents two u ..."
Abstract
-
Cited by 10 (0 self)
- Add to MetaCart
Server applications, and in particular networkbased server applications, place a unique combination of demands on a programming language: lightweight concurrency and high I/O throughput are both important. This paper describes a prototype web server written in Concurrent Haskell, and presents two useful results: rstly, a conforming server could be written with minimal eort, leading to an implementation in less than 1500 lines of code, and secondly the naive implementation produced reasonable performance. Furthermore, making minor modications to a few time-critical components improved performance to a level acceptable for anything but the most heavily loaded web servers. 1 Introduction The Internet has spawned its own application domain: multithreaded server applications, capable of interacting with hundreds or thousands of clients simultaneously, are becoming increasingly important. Examples include FTP (File Transfer Protocol) , E-Mail transport, DNS (name servers), Usenet News,...
Semantics of value recursion for monadic input/output
- Journal of Theoretical Informatics and Applications
, 2002
"... Abstract. Monads have been employed in programming languages for modeling various language features, most importantly those that involve side effects. In particular, Haskell’s IO monad provides access to I/O operations and mutable variables, without compromising referential transparency. Cyclic defi ..."
Abstract
-
Cited by 7 (1 self)
- Add to MetaCart
Abstract. Monads have been employed in programming languages for modeling various language features, most importantly those that involve side effects. In particular, Haskell’s IO monad provides access to I/O operations and mutable variables, without compromising referential transparency. Cyclic definitions that involve monadic computations give rise to the concept of value-recursion, where the fixed-point computation takes place only over the values, without repeating or losing effects. In this paper, we describe a semantics for a lazy language based on Haskell, supporting monadic I/O, mutable variables, usual recursive definitions, and value recursion. Our semantics is composed of two layers: A natural semantics for the functional layer, and a labeled transition semantics for the IO layer. Mathematics Subject Classification. 68N18, 68Q55, 18C15.
Semantics of fixIO
, 2001
"... Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad a ..."
Abstract
-
Cited by 6 (3 self)
- Add to MetaCart
Recent work on recursion over the values of monadic actions resulted in the introduction of a family of fixed point operators, one for each di#erent kind of monadic e#ect. In the context of Haskell, the function fixIO is the corresponding operator for the IO monad. Unfortunately, both the IO monad and fixIO are language primitives in Haskell, i.e. they can not be defined within the language itself. Therefore, any attempt to formally reason about fixIO is futile without a precise semantics for computations in the IO monad. Quite recently, Peyton Jones introduced an operational semantics based on observable transitions as a method for reasoning about I/O in Haskell. Building on this work, we show how one can model fixIO as well, and we argue that it indeed belongs to the family of fixed point operators that enable monadic value recursion.

