Results 11 - 20
of
32
An Operational Semantics for I/O in a Lazy Functional Language
- in Proc Functional Programming Languages and Computer Architecture
, 1993
"... I/O mechanisms are needed if functional languages are to be suitable for general purpose programming and several implementations exist. But little is known about semantic methods for specifying and proving properties of lazy functional programs engaged in I/O. As a step towards formal methods of rea ..."
Abstract
-
Cited by 9 (3 self)
- Add to MetaCart
I/O mechanisms are needed if functional languages are to be suitable for general purpose programming and several implementations exist. But little is known about semantic methods for specifying and proving properties of lazy functional programs engaged in I/O. As a step towards formal methods of reasoning about realistic I/O we investigate three widely implemented mechanisms in the setting of teletype I/O: synchronised-stream (primitive in Haskell), continuationpassing (derived in Haskell) and Landin-stream I/O (where programs map an input stream to an output stream of characters) . Using methods from Milner's CCS we give a labelled transition semantics for the three mechanisms. We adopt bisimulation equivalence as equality on programs engaged in I/O and give functions to map between the three kinds of I/O. The main result is the first formal proof of semantic equivalence of the three mechanisms, generalising an informal argument of the Haskell committee. 1 Introduction and motivation...
Making Choices Lazily
- Proc. FPCA'95, ACM
, 1995
"... We present a natural semantics that models the untyped, normal order -calculus plus McCarthy's amb in the context of call-by-need parameter passing. This results in a singular semantics for amb. Previous work on singular choice has concentrated on erratic choice, a less interesting nondeterministic ..."
Abstract
-
Cited by 8 (3 self)
- Add to MetaCart
We present a natural semantics that models the untyped, normal order -calculus plus McCarthy's amb in the context of call-by-need parameter passing. This results in a singular semantics for amb. Previous work on singular choice has concentrated on erratic choice, a less interesting nondeterministic choice operator, and only in relation to callby -value parameter passing, or call-by-name restricted to deterministic terms. The natural semantics contains rules for both convergent and divergent behaviour, allowing it to distinguish programs that dier only in their divergent behaviour. As a result, it is more discriminating than current domain-theoretic models. This, and the fact that it models singular amb, makes the natural semantics suitable for reasoning about lazy, functional languages containing McCarthy's amb. 1 Introduction The need for non-determinism in functional programming is apparent. There are parallel algorithms that are inherently non-deterministic, deterministic para...
Deterministic Concurrency
- In Proceedings of the 1993 Glasgow Workshop on Functional Programming
, 1993
"... Existing functional languages appear not to be suitable for implementing systems which are inherently concurrent, such as operating system environments. Adaptations to functional languages developed to support such applications have in the past always involved the introduction of non-determinism. ..."
Abstract
-
Cited by 7 (0 self)
- Add to MetaCart
Existing functional languages appear not to be suitable for implementing systems which are inherently concurrent, such as operating system environments. Adaptations to functional languages developed to support such applications have in the past always involved the introduction of non-determinism.
Logic Programming for the Real World
- Proceedings of the ILPS'95 Postconference Workshop on Visions for the Future of Logic Programming
, 1995
"... this paper as an example. However, Mercury is by no means the only possible language design that fits within our proposal's framework. 2.1 A strong type system ..."
Abstract
-
Cited by 7 (0 self)
- Add to MetaCart
this paper as an example. However, Mercury is by no means the only possible language design that fits within our proposal's framework. 2.1 A strong type system
Programming Reactive Systems in Haskell
, 1994
"... Certain classes of applications are naturally described as a network of cooperating components, where each component reacts to input as and when it becomes available. This paper builds on previous work on expressing I/O and state-based algorithms safely in a functional language, and presents a new w ..."
Abstract
-
Cited by 6 (0 self)
- Add to MetaCart
Certain classes of applications are naturally described as a network of cooperating components, where each component reacts to input as and when it becomes available. This paper builds on previous work on expressing I/O and state-based algorithms safely in a functional language, and presents a new way of expressing reactive systems in a functional language that does not violate vital semantic properties. The approach taken is a pragmatic one in that it integrates constructs for expressing reactive systems within existing framework for writing I/O bound, statebased programs functionally. The original contributions of this paper are twofold; first, we show how the existing monadic IO model can be extended to cope with nondeterminism, and secondly, we introduce primitives for evaluating I/O actions concurrently. 1 Introduction A large class of applications are naturally described as a collection of components cooperating to solve some task. Examples include operating systems and graphica...
The Essence of Multitasking
- Proceedings of the 11th International Conference on Algebraic Methodology and Software Technology, volume 4019 of Lecture Notes in Computer Science
, 2006
"... Abstract. This article demonstrates how a powerful and expressive abstraction from concurrency theory—monads of resumptions—plays a dual rôle as a programming tool for concurrent applications. The article demonstrates how a wide variety of typical OS behaviors may be specified in terms of resumption ..."
Abstract
-
Cited by 6 (3 self)
- Add to MetaCart
Abstract. This article demonstrates how a powerful and expressive abstraction from concurrency theory—monads of resumptions—plays a dual rôle as a programming tool for concurrent applications. The article demonstrates how a wide variety of typical OS behaviors may be specified in terms of resumption monads known heretofore exclusively in the literature of programming language semantics. We illustrate the expressiveness of the resumption monad with the construction of an exemplary multitasking kernel in the pure functional language Haskell. 1
Non-Determinism Analysis in a Parallel-Functional Language
, 2000
"... . The paper presents several analyses to detect non-deterministic expressions in the parallel-functional language Eden. First, the need for the analysis is motivated, and then each one is presented. The first one is type-based, while the other two are based on abstract interpretation. Their powe ..."
Abstract
-
Cited by 5 (4 self)
- Add to MetaCart
. The paper presents several analyses to detect non-deterministic expressions in the parallel-functional language Eden. First, the need for the analysis is motivated, and then each one is presented. The first one is type-based, while the other two are based on abstract interpretation. Their power and efficiency is discussed, and an example is used to illustrate the differences. Two interesting functions to adapt abstract values to types appear, and they happen to be a Galois connection. 1 Introduction The paper presents several analyses to determine when an Eden [BLOMP96] expression is sure to be deterministic, and when it may be non-deterministic. The parallel-functional language Eden extends the lazy functional language Haskell by constructs to explicitly define and communicate processes. The three main new concepts are process abstractions, process instantiations and the nondeterministic process abstraction merge. Process abstractions of type Process a b can be compared to ...
A Framework for Deterministically Interleaved Interactive Programs in the Functional Programming Language Clean
, 1994
"... In this paper we present a functional interleaved Event I/O system. This system is a generalization of the Event I/O system as incorporated into the lazy, purely functional programming language Clean. The Inter leaved Event I/O system offers features that are more commonly found outside the functio ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
In this paper we present a functional interleaved Event I/O system. This system is a generalization of the Event I/O system as incorporated into the lazy, purely functional programming language Clean. The Inter leaved Event I/O system offers features that are more commonly found outside the functional scene. These features are dynamic process creation, and two well-known forms of inter-process communication: asynchronous message passing, and data sharing. Both forms of communication are polymorphic and type-safe. As we are working in a functional language, messages can contain higher-order functions and arbitrarily complex algebraic types. Communication by data sharing is a restricted form of communication by global data structures. Nevertheless, the new system is still completely functional because the generalization is done within the pure functional framework. The Interleaved Event I/O system has been implemented and will become part of the new release of Clean. 1 Introduction R...
Deterministic Concurrency
- In [53
, 1993
"... Existing functional languages appear not to be suitable for implementing systems which are inherently concurrent, such as operating system environments or reactive systems. Adaptations to functional languages developed to support such applications have in the past always involved the introduction of ..."
Abstract
-
Cited by 4 (0 self)
- Add to MetaCart
Existing functional languages appear not to be suitable for implementing systems which are inherently concurrent, such as operating system environments or reactive systems. Adaptations to functional languages developed to support such applications have in the past always involved the introduction of non-determinism. This paper proposes an adaptation of a functional language which provides concurrency without the introduction of non-determinism or timing information, and indeed without any alteration to the usual semantics, thus retaining the purely declarative nature of functional programming. The expressiveness of this deterministic form of concurrency is explored by presenting and discussing outlines of designs for a file manager, a window system and a process communication mechanism. Taken together, these demonstrate the feasibility of a deterministic design for a complete single-user concurrent working environment. 1 Introduction Functional languages provide for the simple and sem...
Graphical application and visualization of lazy functional computation
, 1995
"... Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. ..."
Abstract
-
Cited by 2 (1 self)
- Add to MetaCart
Mere academic toys or the tools of the future? Lazy functional programming languages have undoubted attractive properties. This thesis explores their potential, from the programmer's point of view, for implementing interactive and graphical applications to which they do not seem immediately suited. The discussion is centred round two example applications. One is a graphical design program based on an idea of the artist M. C. Escher. The thesis argues that the graphical user interface may be encapsulated in an "interpret " function that when applied by a mouse click to an interface of appropriate type yields the required behaviour. The second example is a monitoring interpreter for a functional language. The idea is that if the mechanics of the reduction are presented at a suitable level of abstraction, this may be used to give insight into what is going on. On the basis of this the programmer might modify the code so that a program runs more efficiently in terms of speed and memory requirements. Problems of displaying the reduction are addressed, and solutions proposed for overcoming these: displaying the graph as a spanning tree, to ensure planarity, with extra leaves

