Annotations to Control Parallelism and Reduction Order in the Distributed Evaluation of Functional Programs

Denotational semantics of a para-functional programming language

“…(2) Where is an unmapped expression evaluated that appears at the top level of a program? (3) Just what are the precise binding rules for the identifier self ? In particular, self in a function body is evaluated when the function is applied, not when it is created, but what exactly does that mean, especially in the context of curried functions?…”

“…Formally, let G be the functional describing E; i.e., E = f ix G (the precise definition of G is easily derived from the equations defining E given in Section 4.1). Next assume that all expressions in a program are unique, 3 and define G by:…”

“…More recently several researchers have used annotations in a parallel programming language. They include Shapiro's "systolic programming" in Concurrent Prolog [20] (whose mapping semantics was derived from earlier work on "turtle programs" in Logo [18]), Keller and Lindstrom's work on distributing data structures in a functional database environment [16], Burton's annotations to the lambda calculus to provide control over "lazy," "eager," and "parallel" execution [3], and Sridharan's "semi-applicative" programming style to control evaluation order [21]. The work presented here, however, is the first that I know of giving a formal semantics to any kind of annotations.…”

Pomset interpretations of parallel functional programs

“…As an operational semantics, pomsets are able to distinguish between call-by-value, call-by-name, callby-need, and call-by-speculation evaluation strategies (even though all but the first of these have the same standard semantics), including the subtle distinction between "lazy evaluation" and "fully lazy evaluation" (which are refiined versions of call-by-need). Furthermore, as a "handle" from which to control operational behavior, pomsets allow us to express most of the behaviors achieved by previously proposed annotations that control not only evaluation order [1,8,14], but also the spatial mapping of program to machine [5,8,12]. In addition, we have used pomset-based annotations to express several other non-trivial operational behaviors, including the routing of data through a multiprocessor network (dually, the path taken in accessing a value), and the synchronized, lock-step execution of two (unrelated) recursive function calls.…”

“…For example, the sequence DT.Ds.D2.R2.Rs.R~ represents the evaluation of x in the first call to f, and DT'Ds.D15"D9.Rg.R15.Rs.R7 represents the evaluation of x in each of the remaining (recuxsive) calls to f. Whereas x's evaluation is only delayed one level upon each call to f, y's evaluation is delayed until the recursion reaches its deepest level, at which point it "unwinds" and "reaches back" to every level above it, performing a additions of 1 We feel that these important yet subtle differences between call-by-value and call-by-need evaluation are made acutely apparent through the use of pomset semantics. where we consider the definitions of f and g to be substituted directly into the result expression (g 10(f a)).…”