Browse Books

Reviewer: Trevor R. Hanson

.abstract LUCID is a functional language, but one which supports variables, i.e., values which change with time. . . . The statements of a LUCID program are equations . . . defining a network of processors and communications lines. LUCIDs dataflow approach to programming . . . [resembles] that of the UNIX shell, with its filters and pipelines. — From the Back Cover Similar comments are found in the publishers advertising. The book evidently promises a novel language based on pipelines and filters. Its publication is noteworthy: dataflow is all the rage today, but books on dataflow languages are few. This book will attract both academic and commercial notice. A detailed review seems appropriate: (1) an overall impression; (2) a summary of the book; (3) a summary of the language LUCID; and (4) a brief assessment. (1) Overall impression—Although many good ideas and insights are to be found, the book was disappointing: it tends to ramble; its tone is whimsical; it is unconvincing. But this indictment is more due to the books missionary task—and tone—than to any individual flaw. (2) The book—LUCID grew from efforts, begun in 1974, to show that a purely declarative language could be adequate for mainstream programming. Pure LISP was discarded—useful LISP applications must rely on “impure” features such as PROG and REPLACA—but this was not thought to reflect a fundamental weakness of applicative languages. It was hoped that a language without assignment or goto statements could give mathematical respectability to practical computation; but this would only be useful if the language were powerful enough to implement complex iterative algorithms. Ultimately, these early project goals—for a new way to write traditional algorithms—were abandoned. This book seeks to prove that the authors model of dataflow computation is a viable alternative to imperative computing, and that LUCID is an appropriate notation for expressing dataflow algorithms. Chapters I–IV chronicle the development of LUCID from a rough idea to a usable language. Chapter V gives examples of LUCID programming—Hammings Problem, enumerating primes, sorting—and contrasts LUCID programming methods with those of imperative languages. Chapter VI presents techniques for transforming one program into another, each yielding identical results but having different semantics (they are thus equivalent); these are useful in refining a computation or in proving assertions. Chapter VII discusses LUCID extensions being considered: i.e., solutions to limitations discussed in earlier chapters. Perhaps the most valuable and readable part of the book is its Appendix, a copy of the programmers guide for an extant LUCID interpreter. This is a well-written manual. It gives a good feel for how the language is actually used; it bears out many of the texts claims, although it seems to belie a few as well. (3) The Language LUCID—LUCID is a descendant of ISWIM. ISWIM was introduced by Landin in 1966 [1], as evidence that purely functional languages need not be notationally inscrutable. ISWIM is actually a family of languages, each based on a given algebra; an ISWIM program is a mathematical expression, without side-effects, having a value with respect to the target algebra. ISWIM uses a where clause to define variables or functions local to an expression; thus ( (( a+ b)2) 2*(( a+ b)2)+1(( a+ b)2) ) 2*3 may be rewritten in simpler form: ( x 2* x+1 x) 2*3 where x=( a+ b)2 end Equations within an ISWIM where clause are definitions: rewrite rules, not executable assignment statements. They may occur in any sequence; they may refer to each other; they may be defined, in turn, by nested where clauses. LUCID programs look like ISWIM programs: both are expressions in a target algebra, supported by where clauses. LUCID adds iteration operators to the target algebra; more important, LUCID introduces a time vector to all data. LUCID variables are thus multivalued: they do not have “current” values, but hold infinite sequences or “histories” of values. They are streams; LUCID expressions are filters acting on those streams, accepting an unending series of inputs, and yielding an unending series of outputs. Thus, length( stg) isnt a single value, but represents a series of lengths, matching a series of strings. The valid filter operations and stream data types are defined by the target algebra. Complex filters are built from simpler ones by “plumbing” them together; pipeline computations are built using standard function notation: “ f( g( x))” means the pipeline x &vbm0; g &vbm0; f.” More complex plumbing can be expressed using where clauses, iteration, and conditionals. This creates an adequate framework for expressing dataflow computations: the nodes and arcs of most dataflow graphs can be expressed as filters and streams in a network of LUCID equations. LUCIDs practical value as a programming language is shown in the UNIX-based LUCID interpreter (documented in the books Appendix, and made publicly available by the authors). LUCID uses a simple algebra with integers, reals, words, strings, and finite lists: the algebra of POP-2 [2]. It is implemented using a demand-driven, garbage-collecting interpreter, which nicely resolves the problems of evaluating nonterminating computations and managing infinite series. The LUCID examples, including a simple but nontrivial screen editor, illustrate that LUCID really can be used to build large programs. (4) Assessment—LUCIDs goals and results are valid; but their presentation seems wrong. The books title and portrayal suggest a structured presentation of a robust tool, a tool in current practical use; something on the scale of the recent Smalltalk books [3] or a standard language reference: an introduction and guide to a mature system. Sweeping claims for LUCID, made in early chapters, could only be borne out in large-scale software development, maintenance, and training. But LUCID is strictly experimental. This book reads like a lecture on the genesis of LUCID, or like a dissertation on a new language idea. It does a fair job at this level: the book is worthwhile, but to a restricted audience. As the text traces LUCID development choices—with dead ends and abandoned constructs sketched along the way—LUCID is shown to be an unfinished solution, an arbitrary point in an evolutionary sequence. The book was generally readable; however, a few specific complaints can be made: :9BAfter tedious discussions of the obvious—e.g., handling conflicts among local variable names—many ideas of real interest are glossed over. Also, important topics are omitted, such as LUCIDs implications for compilers or databases. Other dataflow research receives only cursory treatment; some relevant work is unmentioned. A few examples of the latter: Smalltalk [3]; the &mgr;-calculus [4]; and Hewitts work on actor semantics [5]. A schoolboy humor permeates the book; this is typified by a roasting of most computer scientists, shown in caricature as Cowboy, Wizard, Preacher, Boffin, Mr. Fixit, and Handyman. These images and other witticisms recur throughout the book, and even the index. They are funny, but somewhat inappropriate. LUCID clearly can be used to express dataflow computations; but the reviewer remained unconvinced that LUCID is an appropriate way to do so. In fairness, it must be admitted that the books invitation to use the LUCID interpreter was not pursued; nevertheless, LUCIDs methods and message were presented clearly, and were felt to be understood correctly. LUCID is a vision. Embracing a techical vision is a near-mystical experience; a negative reaction can simply mean that the vision wasnt shared. But the LUCID vision lacks the intuitive clarity and the compelling weight needed to motivate a shift in world view. LUCID is a weak image, compared to past successes: UNIX pipelines; BNF; Smalltalk; the relational calculus. The dataflow model is itself a strong image: tokens flowing from node to node along the arcs of a dataflow template. LUCID gives a way to create these templates in a functional language; but the language doesnt feel like dataflow; it makes dataflow feel like LISP. The LUCID examples dont appear to be better than conventional programs. Although free of internal side-effects, data stream composition and linkage seem abstruse and implicit, as bad as the objectionable parts of traditional languages. LUCID, like other languages, has weaknesses as well as strengths. Perhaps this will change if the language is refined. Who should read this book People designing a dataflow or functional language; people building demand-driven or reduction systems, symbolic manipulators, or bizzare interpreters; people interested in the evolution of programming languages. The ideas are sound. Who should skip this book People seeking an introduction to dataflow concepts; people needing a dataflow language for use today, as an alternative to existing methods; people wanting an example of the dataflow mainstream. The book is frustrating: it offers good ideas, but perhaps in the wrong place. As a snapshot of some valid dataflow research, it is competent. As a paradigm for the next generation of programmers, it must be said to fall short.