Henderson, P., Functional Programming, Prentice-Hall, 1980. 26  Home/Search   Document Not in Database   Summary   Related Articles   Check

....in northern, mesh io2(chart(SOUTH) Li,Lo,Ri,Ro) in southern, rout er (Ri, Ro ) connect (I,Li) connect (0 ,Lo) 10 Related Work Program structuring and reuse are important themes in parallel computing research. These themes are particularly visible in CSP [19] functional programming [21, 18], concurrent logic programming [10, 16] object oriented programming [1] and Unity [7] Most of these systems are based on lightweight process and message passing ideas similar to those explored in this paper. However, for a variety of reasons, they do not support the same forms of composition ....

Henderson, P., Functional Programming, Prentice-Hall, 1980. 26

....specialized versions of the system can bc developed for architectures of particular interest, by rctargcting the final stage of the compiler. 2 Related Work The benefits of an architecturally independent model of parallel computation have been widely recognized in the computer science community [29, 28, 25, 1, 7]. The notion of monotonicity is at the heart of several such programming models, notably concurrent logic programming [11, 24] functional programming [28, 26, 9] and object oriented programming [1] Similarly, concurrent composition underlies such diverse approaches as CSP [29] concurrent logic ....

.... of an architecturally independent model of parallel computation have been widely recognized in the computer science community [29, 28, 25, 1, 7] The notion of monotonicity is at the heart of several such programming models, notably concurrent logic programming [11, 24] functional programming [28, 26, 9], and object oriented programming [1] Similarly, concurrent composition underlies such diverse approaches as CSP [29] concurrent logic programming, functional programming, and Unity [7] Unfor tunately, these models either do not support concurrent source to source transformations or embed the ....

[Article contains additional citation context not shown here]

Henderson, P., Functional Programming, Prentice-Hall, 1980.

....execute in a data driven manner. The execution schedule is then determined by the availability of data and by the scheduling algorithm used to select executable processes. This approach is, of course, well known in actors, dataflow, parallel functional programming, and concurrent logic programming [1, 6, 21, 15]. 5 Interfaces. Concurrently executing program components must be able to share data. As noted above, a mechanism is required that supports encapsulation, that is independent of resource allocation and scheduling decisions, and that is efficient on parallel computers. We achieve this as ....

P. Henderson, Functional Programming. Prentice-Hall, Englewood Cliffs, N.J., 1980.

....obligation generated by the parallelising compiler project mentioned above. Related and future work are outlined in x8 and x9 respectively. Finally we draw our conclusions in x10. 2 Background 2. 1 Accumulator Generalization The introduction of accumulator parameters is a well documented (Henderson, 1980; Bird Wadler, 1988; Turner, 1991; Bird, 1998) technique for deriving efficient functional programs. In order to illustrate the basic idea we use list reversal, a standard text book example (Henderson, 1980) Consider the following naive definition of list reversal: reverse(nil) nil ....

....Generalization The introduction of accumulator parameters is a well documented (Henderson, 1980; Bird Wadler, 1988; Turner, 1991; Bird, 1998) technique for deriving efficient functional programs. In order to illustrate the basic idea we use list reversal, a standard text book example (Henderson, 1980). Consider the following naive definition of list reversal: reverse(nil) nil reverse(X : Y ) app(reverse(Y ) X : nil) where : and app denote list construction and concatenation respectively. An equivalent, but more efficient, version is derived by introducing an additional accumulator ....

Henderson, P. (1980). Functional programming. Prentice Hall.

....predicates for algorithms which do not terminate totally, further developments of our termination methods are required. 4.1. Termination Analysis for Imperative Programs A straightforward approach to prove termination of imperative programs is to transform them into functional ones. See e.g. (Henderson, 1980) for an automated translation. If termination of the resulting functions can be proved, datei.tex; 13 02 1998; 10:59; p.23 24 JRGEN GIESL, CHRISTOPH WALTHER, JRGEN BRAUBURGER then termination of the original imperative program is verified. As an example consider the following imperative program ....

Henderson, P.: 1980, Functional Programming. Prentice-Hall, London.

....hard to perform automatically. Therefore one attempt to verify their termination is to transform imperative programs into functional ones and to prove termination of these corresponding functional programs instead. In this translation, every while loop is transformed into a separate function (see [19] for example) But in general these functions are partial, because termination of while loops often depends on their contexts, i.e. on the preconditions that hold before entering the while loop. So to prove termination of imperative programs in this way, one needs a method for termination ....

....( if even(x) then while(mean(x; 0) double(z) r) else while(pred(x) z; plus(z; r) else r function multiply(x; z : nat) nat ( while(x; z; 0) In general, each program written in our imperative programming language translates into a program of our first order functional language. See e.g. [19] for an automation of this translation. The resulting function multiply is in fact equivalent to the original imperative program, as multiply computes the value of r after execution of the program. In particular, for the termination proof of the imperative program it suffices to show ....

P. Henderson, Functional Programming (Prentice-Hall, London, 1980).

....until it reaches some bound. This class of algorithms is also used extensively in imperative programming languages. A straightforward approach to prove termination of imperative programs is to transform them into functional ones and to verify termination of the resulting functions, cf. e.g. Hen80,GWB98] For example, the imperative program r : 0; while x y do y : y 1; r : r 1 od is transformed into a function whose termination can be proved analogously to minus. Hence, inductive evaluation is particularly useful when extending termination analysis to imperative programs, cf. ....

P. Henderson. Functional programming. Prentice-Hall, London, 1980.

....23] Furthermore, our method could analyze the termination behavior of the 68 examples in [4, 6] where 61 procedures of that collection do not terminate for some input. We also applied our approach to imperative programs by translating them into equivalent functional programs (e.g. according to [14]) where loops often yield partial functions. For instance, the functional procedure first four may result from translating the following while loop. while length(l) 6= s(s(s(s(0) do l : cut(l) od . Following this approach, in 33 of 45 examples from [13] the exact domain ....

P. Henderson. Functional Programming. Prentice-Hall, London, 1980.

....until it reaches some bound. This class of algorithms is also used extensively in imperative programming languages. A straightforward approach to prove termination of imperative programs is to transform them into functional ones and to verify termination of the resulting functions, cf. e.g. Hen80, GWB98] For example, the imperative program r : 0; while x y do y : y 1; r : r 1 od is transformed into a function whose termination can be proved analogously to minus. Hence, inductive evaluation is particularly useful when extending termination analysis to imperative programs, cf. ....

....b) loop(0; 0; n; b) Obviously, the resulting function main is equivalent to the original imperative procedure and in particular, termination of the function main is equivalent to termination of the imperative procedure sum. For a formal definition and an automation of this translation see e.g. Hen80] Note that in general the auxiliary functions resulting from such a translation are partial even if the original imperative procedure terminates totally. The reason is that in imperative procedures, termination of while loops often depends on their contexts, i.e. on the preconditions that hold ....

P. Henderson. Functional Programming. Prentice-Hall, London, 1980.

....r is not bijective, and r cannot be recovered from r=c (unless c is specially constructed to make this possible) In fact, it may be much worse, there may be no s derivable from fc; r=cg such that r=c = s=c. This is the well known disappearance of semantics in metainterpreters (virtual machines) [20]; in Thompson s trojan the semantics that disappear are trojan methods. Normal compiler bootstrapping is expressed as c s =c = c, where the subscript s conveniently denotes the appropriate source code. Bootstrapping is typically achieved by constructing, by hand or by some other means, an ....

Henderson, P. (1980) Functional Programming, Prentice-Hall.

....the operation and latching the results in a special register associated with the FAB, called result register (REG r ) Figure 6 shows the implementation of a primitive operator using its FAB, argument registers, and result register. Note that this corresponds to an applicative order of evaluation [23], i.e. all the arguments are evaluated in parallel. User defined functions appearing in expressions are either synthesized separately (in which case a primitive circuit module implementing the function becomes available) or the definition of the function is first translated into an HFG, and the ....

Henderson, P. Functional Programming. Prentice Hall, 1980.

....proof attempts. Through empirical testing a natural generalization and extension of the basic technique emerged. Here we describe our extended generalization technique together with some promising experimental results. 1 Introduction The introduction of accumulator parameters is a well documented (Henderson, 1980; Bird Wadler, 1988; Turner, 1991) technique for deriving efficient functional programs. In order to illustrate the basic idea we use list reversal, a standard text book example (Henderson, 1980) Consider the following naive definition of list reversal: reverse(nil) nil reverse(X : Y ) ....

....experimental results. 1 Introduction The introduction of accumulator parameters is a well documented (Henderson, 1980; Bird Wadler, 1988; Turner, 1991) technique for deriving efficient functional programs. In order to illustrate the basic idea we use list reversal, a standard text book example (Henderson, 1980). Consider the following naive definition of list reversal: reverse(nil) nil reverse(X : Y ) app(reverse(Y ) X : nil) where : and app denote list construction and concatenation respectively. An equivalent, but more efficient, version is derived by introducing an additional accumulator ....

Henderson, P. (1980). Functional programming. Prentice Hall.

....induction proofs are restricted to the verification of functional languages. Therefore one attempt for automated reasoning about imperative programs is to translate imperative programs into functional programs. In this translation every while loop is transformed into a separate function [Hen80] But note that in general these functions are partial, because in imperative programs, termination of while loops often depends on their contexts (i.e. on the preconditions that hold before entering a while loop) Hence, to apply existing systems for automated program verification to imperative ....

P. Henderson. Functional Programming. Prentice-Hall, London, 1980.

....for x = a and x = a # b. Hence, ofxv depends on oxu both for x = a and x = a # b, so it follows from the stability that ofav = and of (a # b)v = from which o(f a # fb)v = of(a # b)v follows. To conclude: maps in MT are stable and this is expressed by Axiom C. Trivially, maps are also lazy [8]. This requires no further axioms since it is expressed in Axiom PT, Px and xb. Two maps a and b are compatible if there is a map c such that a c and b c. Hence, the stability axiom can be stated: if a and b are compatible, then fa # fb = f (a # b) 2.17 Monotonicity A particularly ....

P. Henderson. Functional Programming. Prentice-Hall, 1980.

....the expression) a VAP node can always be built in this case. Representing lazy expressions in this manner resembles very much an environmentbased technique for the implementation of a functional language (the vector v 1 Delta Delta Delta vm is a tiny environment ) e.g. the lazy secd machine [Hen80, Lan64] or the lazy variant of the categorical abstract machine (cam) CCM85] 3.8 Constructors: CONSTR, SPLIT and CASE Prior to the pattern matching transformation in the compiler (see [Aug85] for details) the concrete data type declarations are processed, and the constructors of each type are ....

P. Henderson. Functional Programming. Prentice-Hall, 1980.

....k log2(n; m) n = 1 n = m k n 6= 0m 6=1 bin vector(n) n 6= 0 Table 1. Functions and their synthesized termination predicates We applied our approach also to imperative programs which may be translated into equivalent functional programs, where loops are often yield partial functions, cf. e.g. [10]. Exploiting also the premises of the termination hypotheses we could generate the exact domain in 27 of 45 examples from [9] Acknowledgements. I would like to thank Hesham Khalil, Stefan Gerberding, Jurgen Giesl, Thomas Kolbe, and Christoph Walther for helpful comments. ....

P. Henderson. Functional Programming. Prentice-Hall, London, 1980.

....specialized versions of the system can be developed for architectures of particular interest, by retargeting the final stage of the compiler. 2 Related Work The benefits of an architecturally independent model of parallel computation have been widely recognized in the computer science community [29, 28, 25, 1, 7]. The notion of monotonicity is at the heart of several such programming models, notably concurrent logic programming [11, 24] functional programming [28, 26, 9] and object oriented programming [1] Similarly, concurrent composition underlies such diverse approaches as CSP [29] concurrent logic ....

.... of an architecturally independent model of parallel computation have been widely recognized in the computer science community [29, 28, 25, 1, 7] The notion of monotonicity is at the heart of several such programming models, notably concurrent logic programming [11, 24] functional programming [28, 26, 9], and object oriented programming [1] Similarly, concurrent composition underlies such diverse approaches as CSP [29] concurrent logic programming, functional programming, and Unity [7] Unfortunately, these models either do not support concurrent source to source transformations or embed the ....

[Article contains additional citation context not shown here]

Henderson, P., Functional Programming, Prentice-Hall, 1980.

....formal specification language based on a finite number of intrinsic types and pre and postcondition assertions. 1 Introduction Executable specifications [Andersen et al. 1992] Hekmatpour and Ince, 1988] Kamin and Kraus, 1993] Tyszberowicz and Yehudai, 1992] Terwilliger and Campbell, 1989] [Henderson, 1986] [O Neill, 1992a] have advantages over nonexecutable specifications as tools for validating specifications against informal requirements, for prototyping, and for testing that implementations satisfy specifications. However, as Hayes and Jones have pointed out [Hayes and Jones, 1989] ....

....in the bodies of quantified assertions, and that only assertions of the form x = val can be used to provide post state values, where val is strictly an expression over pre state values. This is the most prevalent approach, and examples include SMLVIEW [O Neill, 1992a] O Neill, 1992b] me too [Henderson, 1986], EPROL [Hekmatpour and Ince, 1988] Hekmatpour and Ince, 1986] and the technique used for executing IPTES mini specifications [Elmstr m et al. 1993] Larsen and Lassen, 1991] Andersen et al. 1992] The fase3 execution technique [Kamin and Kraus, 1993] Kraus, 1988] can execute a much larger ....

Henderson, P. (1986). Functional programming, formal specification, and rapid prototyping. IEEE Transactions on Software Engineering, SE-12(2).

....are based on a deterministic (typically left most ) evaluation order, there are several reasons to study arbitrary order. One motivation is parallel execution. If the result of evaluation does not rely on evaluation order, then many subexpressions may safely be evaluated in parallel (see [Hen80, Pey87], for example, for related discussion) Another reason to consider arbitrary evaluation order is to identify desirable properties of a particular implementation. For example, if a set of reduction (or execution) rules is confluent, then the result of nondeterministic execution is well defined and ....

P. Henderson. Functional Programming. Prentice--Hall, 1980.

....are based on a deterministic (typically leftmost ) evaluation order, there are several reasons to study arbitrary order. One motivation is parallel execution. If the result of evaluation does not rely on evaluation order, then many subexpressions may safely be evaluated in parallel (see [25, 40], for example, for related discussion) Another reason to consider arbitrary evaluation order is to identify desirable properties of a particular implementation. For example, if a set of reduction (or evaluation) rules is confluent, then the result of nondeterministic evaluation is well defined ....

P. Henderson. Functional Programming. Prentice-Hall, 1980.

....in northern, meshio2(chart(SOUTH) Li,Lo,Ri,Ro) in southern, router(Ri,Ro) connect(I,Li) connect(O,Lo) 10 Related Work Program structuring and reuse are important themes in parallel computing research. These themes are particularly visible in CSP [19] functional programming [21, 18], concurrent logic programming [10, 16] object oriented programming [1] and Unity [7] Most of these systems are based on lightweight process and message passing ideas similar to those explored in this paper. However, for a variety of reasons, they do not support the same forms of composition ....

Henderson, P., Functional Programming, Prentice-Hall, 1980.

....it is also possible to perform termination 5 As mentioned in [Wal94b] one algorithm (greatest.factor) must be slightly modified. analysis for imperative programs: When translating an imperative program into a functional one, usually each while loop is transformed into a partial function, cf. Hen80] Now the termination predicates for these partial loop functions can be used to prove termination of the whole imperative program. Acknowledgements. We would like to thank Christoph Walther and the referees for helpful comments. No Function f f 1 minus(x; y) x y 2 half1(x) even(x) 3 ....

P. Henderson. Functional Programming. Prentice-Hall, London, 1980.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC