Results 1 - 10
of
87
Computational Interpretations of Linear Logic
- Theoretical Computer Science
, 1993
"... We study Girard's Linear Logic from the point of view of giving a concrete computational interpretation of the logic, based on the Curry-Howard isomorphism. In the case of Intuitionistic Linear Logic, this leads to a refinement of the lambda calculus, giving finer control over order of evaluation an ..."
Abstract
-
Cited by 272 (3 self)
- Add to MetaCart
We study Girard's Linear Logic from the point of view of giving a concrete computational interpretation of the logic, based on the Curry-Howard isomorphism. In the case of Intuitionistic Linear Logic, this leads to a refinement of the lambda calculus, giving finer control over order of evaluation and storage allocation, while maintaining the logical content of programs as proofs, and computation as cut-elimination.
Definitional interpreters for higher-order programming languages
- Reprinted from the proceedings of the 25th ACM National Conference
, 1972
"... Abstract. Higher-order programming languages (i.e., languages in which procedures or labels can occur as values) are usually defined by interpreters that are themselves written in a programming language based on the lambda calculus (i.e., an applicative language such as pure LISP). Examples include ..."
Abstract
-
Cited by 263 (2 self)
- Add to MetaCart
Abstract. Higher-order programming languages (i.e., languages in which procedures or labels can occur as values) are usually defined by interpreters that are themselves written in a programming language based on the lambda calculus (i.e., an applicative language such as pure LISP). Examples include McCarthy’s definition of LISP, Landin’s SECD machine, the Vienna definition of PL/I, Reynolds ’ definitions of GEDANKEN, and recent unpublished work by L. Morris and C. Wadsworth. Such definitions can be classified according to whether the interpreter contains higher-order functions, and whether the order of application (i.e., call by value versus call by name) in the defined language depends upon the order of application in the defining language. As an example, we consider the definition of a simple applicative programming language by means of an interpreter written in a similar language. Definitions in each of the above classifications are derived from one another by informal but constructive methods. The treatment of imperative features such as jumps and assignment is also discussed.
The Lazy Lambda Calculus
- Research Topics in Functional Programming
, 1990
"... Introduction The commonly accepted basis for functional programming is the -calculus; and it is folklore that the -calculus is the prototypical functional language in puri ed form. But what is the -calculus? The syntax is simple and classical; variables, abstraction and application in the pure cal ..."
Abstract
-
Cited by 218 (3 self)
- Add to MetaCart
Introduction The commonly accepted basis for functional programming is the -calculus; and it is folklore that the -calculus is the prototypical functional language in puri ed form. But what is the -calculus? The syntax is simple and classical; variables, abstraction and application in the pure calculus, with applied calculi obtained by adding constants. The further elaboration of the theory, covering conversion, reduction, theories and models, is laid out in Barendregt's already classical treatise [Bar84]. It is instructive to recall the following crux, which occurs rather early in that work (p. 39): Meaning of -terms: rst attempt The meaning of a -term is its normal form (if it exists). All terms without normal forms are identi ed. This proposal incorporates such a simple and natural interpretation of the -calculus as
Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine - Version 2.5
- JOURNAL OF FUNCTIONAL PROGRAMMING
, 1992
"... The Spineless Tagless G-machine is an abstract machine designed to support nonstrict higher-order functional languages. This presentation of the machine falls into three parts. Firstly, we give a general discussion of the design issues involved in implementing non-strict functional languages. Next, ..."
Abstract
-
Cited by 180 (19 self)
- Add to MetaCart
The Spineless Tagless G-machine is an abstract machine designed to support nonstrict higher-order functional languages. This presentation of the machine falls into three parts. Firstly, we give a general discussion of the design issues involved in implementing non-strict functional languages. Next, we present the STG language, an austere but recognisably-functional language, which as well as a denotational meaning has a well-defined operational semantics. The STG language is the "abstract machine code" for the Spineless Tagless G-machine. Lastly, we discuss the mapping of the STG language onto stock hardware. The success of an abstract machine model depends largely on how efficient this mapping can be made, though this topic is often relegated to a short section. Instead, we give a detailed discussion of the design issues and the choices we have made. Our principal target is the C language, treating the C compiler as a portable assembler. Version 2.5 of this paper (minus appendix) appe...
The Discoveries of Continuations
, 1993
"... We give a brief account of the discoveries of continuations and related concepts by, A. Van Wijngaarden , A. W. Mazurkiewicz , F. L. Morris , C. P. Wadsworth , J. H. Morris , M. J. Fischer , and S. K. Abdali. ..."
Abstract
-
Cited by 101 (2 self)
- Add to MetaCart
We give a brief account of the discoveries of continuations and related concepts by, A. Van Wijngaarden , A. W. Mazurkiewicz , F. L. Morris , C. P. Wadsworth , J. H. Morris , M. J. Fischer , and S. K. Abdali.
How to Declare an Imperative
, 1995
"... How canweintegrate interaction into a purely declarative language? This tutorial describes a solution to this problem based on a monad. The solution has been implemented in the functional language Haskell and the declarative language Escher. Comparisons are given to other approaches to interaction b ..."
Abstract
-
Cited by 94 (3 self)
- Add to MetaCart
How canweintegrate interaction into a purely declarative language? This tutorial describes a solution to this problem based on a monad. The solution has been implemented in the functional language Haskell and the declarative language Escher. Comparisons are given to other approaches to interaction based on synchronous streams, continuations, linear logic, and side effects.
Forms/3: A First-Order Visual Language to Explore the Boundaries of the Spreadsheet Paradigm
"... Although detractors of functional programming sometimes claim that functional programming is too difficult or counterintuitive for most programmers to understand and use, evidence to the contrary can be found by looking at the popularity of spreadsheets. The spreadsheet paradigm, a first-order subs ..."
Abstract
-
Cited by 81 (37 self)
- Add to MetaCart
Although detractors of functional programming sometimes claim that functional programming is too difficult or counterintuitive for most programmers to understand and use, evidence to the contrary can be found by looking at the popularity of spreadsheets. The spreadsheet paradigm, a first-order subset of the functional programming paradigm, has found wide acceptance among both programmers and end users. Still, there are many limitations with most spreadsheet systems.
Continuation-Based Multiprocessing
, 1980
"... . Any multiprocessing facility must include three features: elementary exclusion, data protection, and process saving. While elementary exclusion must rest on some hardware facility (e.g., a test-and-set instruction), the other two requirements are fulfilled by features already present in applicativ ..."
Abstract
-
Cited by 69 (0 self)
- Add to MetaCart
. Any multiprocessing facility must include three features: elementary exclusion, data protection, and process saving. While elementary exclusion must rest on some hardware facility (e.g., a test-and-set instruction), the other two requirements are fulfilled by features already present in applicative languages. Data protection may be obtained through the use of procedures (closures or funargs), and process saving may be obtained through the use of the catch operator. The use of catch, in particular, allows an elegant treatment of process saving. We demonstrate these techniques by writing the kernel and some modules for a multiprocessing system. The kernel is very small. Many functions which one would normally expect to find inside the kernel are completely decentralized. We consider the implementation of other schedulers, interrupts, and the implications of these ideas for language design. 1. Introduction In the past few years, researchers have made progress in understanding the mecha...
The origins of structural operational semantics
- Journal of Logic and Algebraic Programming
, 2004
"... We review the origins of structural operational semantics. The main publication ‘A Structural Approach to Operational Semantics, ’ also known as the ‘Aarhus Notes, ’ appeared in 1981 [G.D. Plotkin, A structural approach to operational semantics, DAIMI FN-19, Computer Science Department, Aarhus Unive ..."
Abstract
-
Cited by 57 (0 self)
- Add to MetaCart
We review the origins of structural operational semantics. The main publication ‘A Structural Approach to Operational Semantics, ’ also known as the ‘Aarhus Notes, ’ appeared in 1981 [G.D. Plotkin, A structural approach to operational semantics, DAIMI FN-19, Computer Science Department, Aarhus University, 1981]. The development of the ideas dates back to the early 1970s, involving many people and building on previous work on programming languages and logic. The former included abstract syntax, the SECD machine, and the abstract interpreting machines of the Vienna school; the latter included the λ-calculus and formal systems. The initial development of structural operational semantics was for simple functional languages, more or less variations of the λ-calculus; after that the ideas were gradually extended to include languages with parallel features, such as Milner’s CCS. This experience set the ground for a more systematic exposition, the subject of an invited course of lectures at Aarhus University; some of these appeared in print as the 1981 Notes. We discuss the content of these lectures and some related considerations such as ‘small state’ versus ‘grand state, ’ structural versus compositional semantics, the influence of the Scott–Strachey approach to denotational semantics, the treatment of recursion and jumps, and static semantics. We next discuss relations with other work and some immediate further development. We conclude with an account of an old, previously unpublished, idea: an alternative, perhaps more readable, graphical presentation of systems of rules for operational semantics.
Structured programming with go to statements
- Computing Surveys
, 1974
"... A consideration of several different examples sheds new light on the problem of ereat-ing reliable, well-structured programs that behave efficiently. This study focuses largely on two issues: (a) improved syntax for iterations and error exits, making it possible to write a larger class of programs c ..."
Abstract
-
Cited by 49 (2 self)
- Add to MetaCart
A consideration of several different examples sheds new light on the problem of ereat-ing reliable, well-structured programs that behave efficiently. This study focuses largely on two issues: (a) improved syntax for iterations and error exits, making it possible to write a larger class of programs clearly and efficiently without go to state-

