Abstraction Mechanisms in CLU

Comments on:

Liskov, B., Snyder, A., Atkinson, R., and Schaffert, C. (1977). Abstraction Mechanisms in CLU. Communications of the ACM 20(8), August 1977.

Comments from: Peter Brown, Michael Claveria (*), Davis Hart, Alex Leach, Angeline Namai, Mark Nettling, Dimitar Tasev, Dave Ventresca (-).

No comments from: Brad Miller (x).

For data abstraction to be understandable at an abstract level, the authors claim that the behavior of those data objects must be completely characterized by those operations. Does this mean that they should not be affected by other operations that affect other types of data objects? Is this a problem when one wants to add another operation to an existing set of data objects? How does the linguistic construct "cluster" work? Are there any other languages beside CLU that support procedural and data abstractions? Are there any other programming languages that use an iterator like construct for control abstraction? I don't understand the idea behind logical containment. How is it possible for an object to contain itself?

On a more specific note, I was confused by their definition of assignment (pg 570). It says that the in the case of x := y, the object is not copied, rather it is shared by both x any y. does this mean that if you type:

x := 1
y := 2
x := y
y := y+3

is x equal to 2 or 5?

2. You need to realize that there's a big difference between assignment and mutation. The assignment y := y+3 builds the object 5 and makes y refer to it; it does not modify y.

I also noticed that types we normally regard as primitives (integers, booleans, characters, and strings) are constants. It seems that this constraint requires that the programmer reassign new primitive values to a variable every time he wishes to change a variable's value. However, to handle this efficiently in the language, wouldn't you want to change the data stored in the memory location, violating the languages own specification of a "constant"?

See the note above.

What is the purpose of "cvt" in 3.3? Is there an advantage to convert between the abstract and representation types? It seems that for the code to be useful, it shouldn't be in the abstract type anyway.

From the paper, I understood that the key features of CLU are data abstraction, which allows the decomposition of implementation and use, and control abstraction, which allows the programmer to isolate the selection of an object from the action to be performed on that object. The discussion on the relationship between abstract and representation types also reminds me of the interface-class or superclass-subclass relationship. The paper doesn't explicitly mention inheritance, but Liskow, Snyeder etc. seem to imply inheritance when they go into the discussion of Cvt and conversion, which I think is the equivalent of casting. Actually, with the exception of the compile-time type checking, I find CLU quite reminiscent of Java.

I'm fairly certain that I don't understand the full significance of abstract typing. It seems fairly complicated and almost as if they have to modify a large number of things to keep the typing abstract. wouldn't a language that perhaps supported both strong and weak typing be better than either? Some of the things about CLU I thought were insightful and much more efficient, but I still got the impression that they seem to be forcing abstract typing to work well. Overall, I'm confused. I'm not sure what to think about the importance of strong typing vs abstract typing. Perhaps coding in a language like CLU would help to broaden my understanding of what it means to have a language that focuses on abstraction rather than defined types.

I like the concepts presented in the introduction. However, when reading the example code however, it seemed that the major difference in CLU from other languages is that you can make an object within a program and have the ability to use that object throughout your program. This seems similiar to Java's anonymous inner classes, but is perhaps a clearer way to write these objects. It also would help reduce the number of classes made in OOP that are only made for use in one program, and reduce documention and time to locate these classes. Overall, the "abstract" data typing is a good concept which helps programming become easier. Although, I do not think it allows things that were not possible before.

CLU seems to be a rather successfully designed programming language. I am extremely keen on these attributes of CLU:

• input and output streams are data abstractions; // this is definitely simpler than java's concept of buffers.
• control abstraction and iterators; // extremely powerful tool given in the hands of the programmer.
• differentiation between implementations and modules; // java's concept that everything is a class does not hold for primitives, and makes differentiation betweeen data and executables impossible.
• complete and successful type checking;

On the other hand, I am concerned about the following:

• maintaining the CLU library can be memory intensive;
• compiling with the use of such a huge library can be time consuming. One of the first things I found myself wondering was what programming languages were like before these three types of abstraction were introduced. Did they use them, with out explicitly defining or did they somehow now use them at all. I understand the author's point that different languages make various abstractions easier or harder, however, the authors make it sound (at least to me) as though they were the first ones to think of abstracting these parts of the program.

The CLU language almost exactly describes some of the key elements of Java. It describes data types, their definitions, and even generics. However, I was interested by the differences between the two. For example, CLU requires that any "casting" caused by cvt and oneof be handled by a tagcase control strucutre - making for a very strict typing interface. The designers foreshadow Java's convention of casting and exception handling and the problems it can create by allowing programmers to avoid strict typing rules by noting that "conventions are no substitue for enforced constraints".