Position Paper 3: CLUless?

University of Virginia, Department of Computer Science
CS655: Programming Languages
Spring 2000

Position Paper 3
Michael Walker
28 February 2000

CLUless? A Comparison of CLU and ADA Language Design and Development

The History

ADA, named after Ada Augusta Byron, Lady Lovelace [6], was a language established in 1979 through efforts from the US Department of Defense (DoD). Its creation was motivated by the need for a single, high-order language appropriate for embedded systems programming, which was previously consuming more than half of the DoD's $3 billion in expenses in software costs [1][2]. As a first measure of how the new language was to be created, DoD chose to evaluate the existing programming languages for applicability. Their evaluation list consisted of 23 languages, from which a few appropriate languages were chosen to serve as the basis for ADA's eventual development. This evaluation occurred in 1976 as a preliminary investigation that would lay the foundations for ADA.

CLU, a language designed by Barbara Liskov and others at the Massachusetts Institute of Technology (MIT), was not included in DoD's evaluation. CLU, short for "cluster", began development in 1972, primarily as a research effort on programming methodology [3]. The research was funded by another government agency (DARPA), and was designed to be a practical tool for complex software systems [3]. Although CLU is not widely in use today, it made notable progress in programming abstractions, especially in user-defined data abstractions.

Because CLU was a contemporary language of ADA, one wonders why CLU was not among the evaluation languages selected by the DoD in its effort to write ADA.

 

Design Goals and Implementation: ADA

To answer the above question, it must first be shown that the design goals of CLU were desirable and compatible ones for ADA to consider in their evaluation. DoD was interested in designing a language for use with critical embedded systems, including military applications for weapon systems, communications systems, and other uses [2]. As such, ADA would have to be general enough to program for many different embedded applications, and would require real-time control mechanisms [1]. Reliability was essential for such a language, as is efficiency both in time and space, as many embedded systems have very limited spatial and temporal resources. Furthermore, DoD wanted to reduce the effort and cost of rewriting software by increasing code maintainability, which put a high priority on clarity, readability, extensibility, and the lack of any implicit operations that might give the programmer unexpected results.

These criteria were reflected in the implementation of what would become the ADA programming language. ADA is strongly typed, which forces more compile-time errors, but eliminates the chance for run-time type errors, which could otherwise severely damage the performance of critical applications. Type binding was done at compile time, which increased code speed and reliability. Arithmetic types were especially designed with exact precision in mind. For instance, integers and fixed point numbers were exact numeric values, and would not allow rounding or truncation. Implicit conversions between types (say, between int and float) was also not allowed, and explicit conversion operations were predefined only for types for which no unreasonable loss of information would occur. The strong type system in ADA ensured the reliability of the language, and was a primary component of its implementation [1].

However, the strict requirements upon the type system were complemented by its data abstraction mechanisms, which added power and flexibility to the language. ADA allowed for arrays, records, variants, and user-defined types. Most importantly, ADA used a structuring unit known as a package to encourage encapsulation and information hiding. A package consisted of two parts: (1) the specification, describing the functions of the particular package, and (2) the implementation, specifying the underlying operations of that package and the persistent data associated with the package. The two elements could be separated, and even compiled separately, allowing for information hiding in data abstraction. Information within a package marked as "private" would be inaccessible to any code outside the package implementation, which allows for increased enforcement of data security. Genericity was even supported by ADA through the generic keyword. In total, ADA supported desirable data abstraction principles that allowed for extensibility and easier code maintenance and reuse, without sacrificing security or reliability [2].

 

Design Goals and Implementation: CLU

Interestingly, CLU was specifically designed to provide extensive support for data abstraction mechanisms, and also had a strong type system. CLU enforced strong typing and static type binding, and all variables must be declared with a type associated with it, so all type errors could be caught at compile time [4]. By language definition, basic types like integers were an undefined range, and the exact range was left up to the particular implementation. As far as can be told from the CLU reference manual, CLU does not allow type casting or implicit conversion, but it does appear to allow truncation when dividing two integers [5].

CLU's greatest strength is in its support for three types of abstractions: procedural, control, and data abstractions. The procedural abstractions are supported by procedures, which was not a new idea. However, CLU offered support in addition to traditional control abstractions by adding the iterator. The iterator can be used inside the for loop (another control abstraction) to navigate through the elements in a collection without having to reveal the inner structure of the collection itself. This was created in conjunction with exceptional support for data abstractions in CLU. The CLU cluster, for which the language is named, allows for separation of the cluster abstraction and it's implementation module, and supports separate compilation. The representation inside a module cannot be accessed by code outside the module, and conversion of a cluster object into its representation is not allowed. Furthermore, parameterized clusters allow for code genericity, increasing the possibilities for code reuse without sacrificing the principles of information hiding [4].

 

CLUless?

The data abstraction mechanisms supported by CLU are quite similar in specification and in use when compared to ADA's equivalent mechanism, and one wonders why CLU was not listed as a DoD evaluation language when ADA was in its infancy. Also, CLU iterators are a sophicisticated idea that is absent from ADA, and could have been very useful for defining additional control structures that increase code reliability. Iterators would have been written by the package designer, and as such, would have been less likely to fail than would a plain for loop on a package, which risks out-of-bounds errors. Indeed, much effort and money may have been saved, had the ADA committee turned to CLU for inspiration in their design strategy.

However, it may not be fair to lay blame on the DoD in hindsight. ADA was proposed for embedded, real-time systems, and DoD accordingly focused on practical languages, proven over time, and used by professionals [1]. CLU was developed by university researchers as a new and unproven approach to programming, and without modification, would not have been a good choice for the new embedded systems langauge for the DoD (for instance, it does not support parallel processing, and uses garbage collection, which detracts from its effectiveness as a real-time programming language). The designers of CLU described their work primarily as "concepts rather than the languageÓwe thought of our primary output as being publicationsÓwe did not think of CLU as a language that would be exported widely. Instead, we were concerned primarily with the export of ideas" [3].

The CLU reference manual was not even published until July 1978, one month after the final STEELMAN language sepcification had been released, and a full two years after ADA had made its language design basis choices. Given the limited amount of information available to the public before this time, it would be unreasonable to expect the DoD to put much effort into choosing CLU as a basis for its language design. The fact that both languages separately developed similar data abstraction mechanisms is a curious one, especially for the programming language analysts that enjoy speculation (like myself), but can be considered a coincidence of the times, rather than a reflection of ignorance of the DoD programming languages committee.

 

References

 

[1] Department of Defense Requirements for High Order Computer Programming Languages: "STEELMAN". US Department of Defense, 1978.

[2] Barnes, J.P.G. "An Overview of Ada". Software Practice and Experience, Vol. 10, 1980, pp. 851-887.

[3] Liskov, Barbara. "A History of CLU". ACM SIGPLAN Notices, 28:3, 1993.

[4] Liskov, B., Snyder, A., et al. "Abstraction Mechanisms in CLU". Communcations of the ACM, 20:8, 1977, pp. 564-576.

[5] Liskov, B. "Appendix A", CLU Reference Manual. 1978.

[6] Duncan, C.W. "Letter to The Earl of Lytton", The Secretary of Defense, Washington, 1979.

 

Collaborators

Thanks goes to Ying Lu, who helped review this paper for editing.

 


University of Virginia
CS 655: Programming Languages

mwalker@virginia.edu
Last modified: Tue Jan 18 11:10:50 2000