Results 1 
3 of
3
Calculating Functional Programs
 Algebraic and Coalgebraic Methods in the Mathematics of Program Construction, volume 2297 of LNCS, chapter 5
, 2000
"... A good way of developing a correct program is to calculate it from its specification. Functional programming languages are especially suitable for this, because their referential transparency greatly helps calculation. We discuss the ideas behind program calculation, and illustrate with an examp ..."
Abstract

Cited by 26 (8 self)
 Add to MetaCart
A good way of developing a correct program is to calculate it from its specification. Functional programming languages are especially suitable for this, because their referential transparency greatly helps calculation. We discuss the ideas behind program calculation, and illustrate with an example (the maximum segment sum problem). We show that calculations are driven by promotion, and that promotion properties arise from universal properties of the data types involved. 1 Context The history of computing is a story of two contrasting trends. On the one hand, the cost and cost/performance ratio of computer hardware plummets; on the other, computer software is overcomplex, unreliable and almost inevitably over budget. Clearly, we have learnt how to build computers, but not yet how to program them. It is now widely accepted that adhoc approaches to constructing software break down as projects get more ambitious. A more formal approach, based on sound mathematical foundations, i...
Making the pointfree calculus less pointless
 In 2nd. APPSEM II Workshop
, 2004
"... Functional programming is particularly well suited for equational reasoning – referential transparency ensures that expressions in functional programs behave as ordinary expressions in mathematics. However, unstructured programming can still difficult formal treatment. As such, when John Backus prop ..."
Abstract

Cited by 1 (0 self)
 Add to MetaCart
Functional programming is particularly well suited for equational reasoning – referential transparency ensures that expressions in functional programs behave as ordinary expressions in mathematics. However, unstructured programming can still difficult formal treatment. As such, when John Backus proposed a new functional style of programming in his 1977 ACM Turing Award lecture, the main features were the absence of variables and the use of functional forms or combinators to combine existing functions into new functions [1]. The choice of the combinators was based not only on their programming power, but also on the power of the associated algebraic laws. Quoting Backus: “Associated with the functional style of programming is an algebra of programs [...] This algebra can be used to transform programs and to solve equations whose “unknowns ” are programs in much the same way one transforms equations in highschool algebra”. This style of programming is usually called pointfree, as opposed to the pointwise style, where the arguments are explicitly stated. The basic set of combinators used in this paper as been already extensively presented in many publications, such as [6], and includes the typical products, with split ( · △ ·) and projections fst and snd, sums, with either ( · ▽ ·) and injections inl and inr, and exponentials, with curry · and application ap.
Refactoring for Comprehension
"... Functional programming is well suited for equational reasoning on programs. In this paper, we are trying to use this capability for program comprehension purposes. Specifically, in a program understanding process, higherorder operators can work like abstract schemes in which we can fit formal speci ..."
Abstract
 Add to MetaCart
Functional programming is well suited for equational reasoning on programs. In this paper, we are trying to use this capability for program comprehension purposes. Specifically, in a program understanding process, higherorder operators can work like abstract schemes in which we can fit formal specifications calculated from the source code. Such specifications are calculated by a transformational process which we call reverse program calculation that operates on both notations: pointwise and pointfree. Once a specification matches an abstract schema, a new refactoring phase leading to a clearer source code takes place. At the same time, an unambiguous behavioural understanding is reached because we give a mathematical description of the abstract schemes. To provide a more complete and realistic perspective of the approach, we use recursive operators that can handle side effects.