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

Position Paper 2
Michael Walker
February 21, 2000

A Comparison of Arrays in ALGOL 68 and BLISS

Array Mechanisms in ALGOL 68

ALGOL 68 was designed to be an improvement upon ALGOL 60. In ALGOL 60, arrays could be multi-dimensional, they could be dynamically sized, and their lower bound index could be non-zero [1]. ALGOL 68 augments the array conventions already offered by ALGOL 60. In ALGOL 68, an array must have a type (or "mode") associated with it, and is declared as such:

[1:10] int arrayA68;

As in ALGOL 60, arrays could also have non-zero array bounds. In this case, the array index starts at 1 and spans 10 entries, ending at 11. This convention allowed for more flexibility in programming, but increased the number of calculations in the array accessing equation.

ALGOL 68 also supports multi-dimensional arrays, and extends the same array accessing equation for multiple dimensions. The general array accessing equation for a two-dimensional array is:

c + (i-l1) * s1 + (j-l2) * s2

where c is the array origin, l is the lower bound of each dimension, and s is the stride, based on the type of which the array contains.

ALGOL 68 took advantage of this property of its arrays, and offers slices [2]. A subsection of any array can be specified, or "trimmed", yielding a portion of the original array. This is useful for assigning a slice of a multi-dimensional array to another, differently-sized array.

ALGOL 68 allows flexible arrays, which lets the size of an array variable to be changed dynamically according to what it is assigned. This feature was originally provided to allow an easy array implementation of strings, because a string often changes size as it is assigned values of different lengths. For example:

mode string = flex [1:0] char;

declares a user-defined mode (or type) called string, and makes the string a flexible array, originally of size 0. Later in the program, a user might assign variable-length words to a string, and would not have to worry about allocating enough space for the string:

string = "str";
string = "A longer string";

By definition, assigning new values to a flexible array would overwrite, rather than append, its new value over the old one. Many programmers would rather have the semantics be the other way around, but because flexible arrays were designed with strings in mind, the design choice was the opposite [4].

Array Mechanisms in BLISS

BLISS was originally designed to accommodate systems programmers that required powerful data structures and system-level access to those structures. BLISS' array support was in perfect accord with this design goal. Although its syntax resembles ALGOL, the similarities between the two are few.

BLISS arrays do not have manifest type information associated with them, and can thus hold heterogeneous elements, in the sense that their elements can be of different uses to the user. However, arrays must hold one or more words, where a word is the 36-bit unit of storage in BLISS, so in this sense, arrays are homogeneous collections.

Because type information is not necessary, array declarations in BLISS are simple. The array name is followed by its number of words, and optionally prefaced by a global, local or own keyword, which modifies the scope and/or persistence of the array's contents:

own arrayBLISS[100];

In its implementation, arrayBLISS is actually a pointer to the first word of the 100-word array segment [5]. If a programmer increments arrayBLISS, then arrayBLISS will point to the next word in the array (much like C supports).

Multi-dimensional arrays are supported in BLISS, but more interestingly, general functions can be associated with arrays, and used in conjunction with them. These functions can do operations to the elements of an array, and can even be written to dynamically allocate space for an array that has run out of space. In this way, dynamically-sized arrays are supported--the user can use them, as long as he or she has previously specified an allocation function specified for that array. Moreover, the functions can be generalized such that they can be used for arrays of different sizes. This was part of BLISS' attempt to separate the definition of a structure from the algorithmic functions used to operate on that structure [5]. By doing so, a programmer could write a dynamic allocation function for multi-dimensional arrays, associate this function with specific arrays in the program, and use the function whenever it was appropriate. This is an early example of language support for code reuse.

Design Motivations

The designers of BLISS and ALGOL 68 had greatly different design motivations, and this greatly influenced their decisions in implementing arrays in the language. ALGOL 68 was meant to improve upon an already existing general-purpose programming language that had been well-established as the best language for formal analysis of programming to date. In doing so, the designers aimed to please a large group of users and theoreticians already used to using ALGOL 60, and also attempted to extend its generality and usefulness by insisting on strict orthogonality of its components.

Arrays in ALGOL 68 are full of expressive power, and contribute to the language's usefulness in reasoning about general programming strategies. However, the complexity of arrays adds to the overall language complexity, and allows more chances for programmer error.

The ability to have non-zero lower bounds for arrays is useful for reasoning about collections of data that may not be logically numbered starting at zero. However, this irregularity is easy to overlook in programming. A user could easily misinterpret the arrayA68 array and attempt to assign to arrayA68[0], which is not a valid index. Even worse, this problem could be hidden by using an index variable instead of a constant. Because there is no out-of-bounds array index checking, the improper index variable would generate a run-time error.

The ability to slice multi-dimensional arrays is a valuable feature that has made programmers wonder "why other languages (excepting, in some degree, PL/I) have not done the same" [4]. The possibility of extracting the diagonal of an array matrix is an attractive mathematical construct that is entirely possible in ALGOL 68.

Flexible arrays were, as previously described, originally designed with strings in mind. However, their usefulness extends far beyond strings. Any list of varying size could be kept in a flexible array, and the user could abstract away the details of dynamic array allocation. This is convenient for users that did not wish to worry about memory management, and is more suitable for theoretical programmers than for systems experts that must conserve space and time more strictly.

BLISS designers had completely different goals in mind, and the arrays in BLISS resemble more practical goals. The language was originally offered as an alternative to assembly for the PDP-10, and was necessarily designed to provide access to hardware features of the machine while maintaining efficiency.

Thus, there was no type checking associated with arrays (or any variables, for that matter). This speeds up the language in every way, but makes it vulnerable to a vast assortment of programmer errors. Furthermore, by putting the responsibility of dynamic array allocation in the programmer's hands, BLISS made bad programs very easy to write. However, the language designers assumed that the systems programmers using BLISS were to be extremely careful about their code, and traded safety for accessibility and flexibility in a big way.

Advantages and Extensions

ALGOL 68 was simply a more complete language than BLISS, and offered much more built-in support for arrays. However, BLISS was created to be a powerful base from which more complicated, systems-level tools could be constructed for the PDP-10. As such, there is no reason that a motivated systems programmer could not implement any or all of the desirable features supported by ALGOL 68. For instance, slices could be implemented as a user-defined function, made generic for arrays of any type. This function could then be associated with the arrays as the programmer deems necessary, rather than being an extension provided by default. Similarly, flexible arrays could be simulated with a user-defined dynamic allocation function, "appropriate to his [sic] own application" [5].

This type of extension was anticipated and even encouraged by the designers of BLISS, but is it a good idea? At the time, it may have been. Systems programmers were assumed to handle all possible problems with low-level coding, and may desire their own implementation of slicing or dynamic arrays over the language definition's attempt. However, putting this kind of power in the user's hands has become increasingly harmful, and is not common practice today. The complexity involved in handling system-level errors in large software systems can simply become too great for even the best programmers. Instead, the language designers should attempt to provide reasonable default implementations, and allow the ambitious programmer a way to override them if they wish. In programming today, the type of extreme flexibility found in BLISS has been abandoned for better structure in language design.


[1] Nauer, P, ed. "Report on the Algorithmic Language ALGOL 60". Communications of the ACM, Vol 6:1, 1963, pp. 1-17.

[2] "ALGOL 60 Language Summary". ACM SIGPLAN Notices, from ACM Sigplan History of Programming Languages Conference, Vol. 13:8, 1978.

[3] van Wijngaarden, A, Mailloux, B.J., et al, "Revised Report on the Algorithmic Language ALGOL 68". Acta Informatica 5, 1975.

[4] Lindsey, C.H. "A History of ALGOL 68". The Second ACM SIGPLAN Conference on History of Programming Languages, Apr. 20-23, 1993, pp. 97-132.

[5] Wulf, W.A., Russell, D.B., and Habermann, A.N. "BLISS: A Language for Systems Programming". Communications of the ACM, 14:12, 1971, pp. 780-790.



I had my report reviewed by Hexin Wang. Thanks goes to him for helping me fix some errors.

  CS 655
University of Virginia
CS 655: Programming Languages
Last modified: Tue Jan 18 11:10:50 2000