Logic programming and functional programming row in the same boat. Methods used to achieve success with one often transpose to the other, and both face similar obstacles. Here I offer a compendium of success stories for functional programs, followed by a list of obstacles to more widespread use of functional programming, in the belief that much of this experience is relevant to logic programmers. This material first appeared as columns in ACM SIGPLAN Notices [29, 30]. The final section contains a few remarks specific to the relations between functional and logic programming. 1 An angry half dozen “Have you used it in anger yet?” The time is a dozen years ago, the place is Oxford, and my fellow postdoc has just scrutinized my new bike. He’s admired the chrome, checked the gears, noted the Kryptonite lock. Now he wants to know if I’ve used it to serious purpose. Gleaming chrome is well and good, but will it run you through the woods? “Have you used it in anger yet?”

Some applications are most easily expressed in a programming language that supports concurrency, notably interactive and distributed systems. We propose extensions to the purely-functional language Haskell that allow it to express explicitly concurrent applications; we call the resulting language Concurrent Haskell. The resulting system appears to be both expressive and efficient, and we give a number of examples of useful abstractions that can be built from our primitives. We have developed a freely-available implementation of Concurrent Haskell, and are now using it as a substrate for a graphical user interface toolkit. This paper appears in the Proceedings of the 23rd ACM Symposium on Principles of Programming Languages (POPL '96), St Petersburg Beach, Florida, Jan 1996. 1 Introduction Concurrent Haskell is a concurrent extension to the lazy functional language Haskell. Our principal motivation is to provide a more expressive substrate upon which to build sophisticated I/O-perform...

Comonads are mathematical structures that account naturally for effects that derive from the context in which a program is executed. This paper reports ongoing work on the interaction between recursion and comonads. Two applications are shown that naturally lead to versions of a comonadic fold operator on the product comonad. Both versions capture functions that require extra arguments for their computation and are related with the notion of strong datatype. 1 Introduction One of the main features of recursive operators derivable from datatype definitions is that they impose a structure upon programs which can be exploited for program transformation. Recursive operators structure functional programs according to the data structures they traverse or generate and come equipped with a battery of algebraic laws, also derivable from type definitions, which are used in program calculations [24, 11, 5, 15]. Some of these laws, the so-called fusion laws, are particularly interesting in p...

Some algorithms make critical internal use of updatable state, even though their external specification is purely functional. Based on earlier work on monads, we present a way of securely encapsulating stateful computations that manipulate multiple, named, mutable objects, in the context of a non-strict, purely-functional language. The security of the encapsulation is assured by the type system, using parametricity. The same framework is also used to handle input/output operations (state changes on the external world) and calls to C.