In this paper we present a non-deterministic call-by-need (untyped) lambda calculus nd with a constant choice and a let-syntax that models sharing. Our main result is that nd has the nice operational properties of the standard lambda calculus: confluence on sets of expressions, and normal order reduction is sufficient to reach head normal form. Using a strong contextual equivalence we show correctness of several program transformations. In particular of lambdalifting using deterministic maximal free expressions. These results show that nd is a new and also natural combination of non-determinism and lambda-calculus, which has a lot of opportunities for parallel evaluation. An intended application of nd is as a foundation for compiling lazy functional programming languages with I/O based on direct calls. The set of correct program transformations can be rigorously distinguished from non-correct ones. All program transformations are permitted with the slight exception that for transformations like common subexpression elimination and lambda-lifting with maximal free expressions the involved subexpressions have to be deterministic ones.

"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?" Having read the title of this column, you may have just asked the same question, though perhaps in different words. You've scrutinized functional languages. You've admired the elegance of lambda calculus, checked the benchmarks from the compilers, noted the security provided by strong typing. Now you want to know if they have been used to serious purpose. Mathematical elegance is well and good, but will it run that mission-critical system? Here are a half-dozen examplars of functional programs used in anger.

This paper proposes a non-standard way to combine lazy functional languages with I/O. In order to demonstrate the usefulness of the approach, a tiny lazy functional core language “FUNDIO”, which is also a call-by-need lambda calculus, is investigated. The syntax of “FUNDIO ” has case, letrec, constructors and an IO-interface: its operational semantics is described by small-step reductions. A contextual approximation and equivalence depending on the input-output behavior of normal order reduction sequences is defined and a context lemma is proved. This enables to study a semantics of “FUNDIO ” and its semantic properties. The paper demonstrates that the technique of complete reduction diagrams enables to show a considerable set of program transformations to be correct. Several optimizations of evaluation are given, including strictness optimizations and an abstract machine, and shown to be correct w.r.t. contextual equivalence. Correctness of strictness optimizations also justifies correctness of parallel evaluation. Thus this calculus has a potential to integrate non-strict functional programming with a non-deterministic approach to input-output and also to provide a useful semantics for this combination. It is argued that monadic IO and unsafePerformIO can be combined in Haskell, and that the result is reliable, if all reductions and transformations are correct w.r.t. to the FUNDIO-semantics. Of course, we do not address the typing problems the are involved in the usage of Haskell’s unsafePerformIO. The semantics can also be used as a novel semantics for strict functional languages with IO, where the sequence of IOs is not fixed.

structures. Over twenty commercial applications have been developed in Natural Expert, including IVANHOE, which invoices services for every flight passing through Orly or Roissy airport in Paris. Erlang is an strict functional language, used by Ericsson to program telecommunications switches [2]. Erlang fuses ideas from functional and concurrent languages. On the functional side it provides ease of allocating, traversing, and deallocating complex structures; on the concurrent side it provides processes, To appear in ACM Computing Surveys, June 1996. message passing, and distribution. Synergy arises because the messages passed are complex structures; for instance, functional pattern matching may determine which concurrent message to receive. Strictness is essential to make it easy to predict the order in which concurrent operations occur. Several hundreds of thousands of lines of Erlang code appear in Ericsson products, and it has been f

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?”

We investigate the extension of non-strict functional languages like Haskell or Clean by a non-deterministic interaction with the external world. Using call-by-need and a natural semantics which describes the reduction of graphs, this can be done such that the Church-Rosser Theorems 1 and 2 hold. Our operational semantics is a base to recognise which particular equivalencies are preserved by program transformations. The amount of sequentialisation may be smaller than that enforced by other approaches, and the programming style is closer to the common one of side-effecting programming. However, not all program transformations used by an optimising compiler for Haskell remain correct in all contexts. Our result can be interpreted as a possibility to extend current I/Omechanism by non-deterministic memoryless function calls. For example, this permits a call to a random number generator. Adding memoryless function calls to monadic I/O is possible and has a potential to extend the Haskell I...