Progress in Programming Languages

KIM B. BRUCE
Williams College ^[email protected]&

A great deal of progress has been made pieces, each of which can be separately
over the last forty years in the design compiled. However, since these different
and implementation of programming compilation units depend on each other,
languages. Unfortunately, most pro- there must be a way of reliably passing
grammers have little experience with type information from one unit to the
imperative programming languages de- next. C provides primitive facilities to
veloped after the early 1970s, and still support this with header files, while the
use older languages like FORTRAN, (non-standard) Pascal units provide
COBOL, Pascal, and C. Yet in the last somewhat better support (though with-
twenty or so years there have been im- out information hiding). Modula-2 and
portant improvements to these lan- Ada-83, on the other hand, support sep-
guages. arate compilation by providing separate
Perhaps the most important develop- specification and implementation units.
ment has been the introduction of fea- This allows programs to be compiled
tures that support abstract data types once the imported units specifications
(ADTs). These features allow program- have been defined, while leaving the
mers to add new types to languages that implementations to be compiled later.
can be treated as though they were In fact, programmers may interchange a
primitive types of the language. The variety of implementations of specifica-
programmer can define a type and a tions without having any impact on the
collection of constants, functions, and code of programs using these units.
procedures on the type, while prohibit- Clu and Ada-83 also provided support
ing any program using this type from for parameterized types and polymor-
gaining access to the implementation of phic operations by allowing parameter-
the type. In particular, access to values ized ADTs. For instance, in Ada-83 one
of the type is available only through the can specify a parameterized binary
provided constants, functions, and pro- search tree as:
cedures. Simula-67 was one of the first generic
type BSTElt is private
languages to provide support for ADTs,
with function LessThan(x, y:
though it did not provide support for BSTElt) return BOOLEAN;
hiding the representation of types. For package BinSrchTree is
example, in the mid-’70s Clu’s clusters . . .
provided full support for ADTs. Two of end BinSrchTree;
the more popular languages providing This package can then be instantiated
full support for ADTs (though using with any type T that has an appropriate
slightly different mechanisms) are LessThan function defined for it. More-
Modula-2 and Ada-83. over, in both Clu and Ada-83 these pa-
These languages have also provided rameterized ADTs can be type checked
better support for separate, but not in- before being instantiated, which guar-
dependent, compilation. That is, pro- antees that instantiated versions will be
grams can be broken into smaller free of type errors as long as the opera-

This research was partially supported by NSF grant CCR-9424123.

Copyright © 1996, CRC Press.

ACM Computing Surveys, Vol. 28, No. 1, March 1996

246 • Kim B. Bruce

tions required in the declaration exist. based rather than object-oriented, be-
The ability to define such parameter- cause of the different point of view and
ized ADTs is clearly very useful to pro- because they lack features like subtyp-
grammers. ing and inheritance commonly found in
At least partially in response to the object-oriented languages.) Many of
concerns raised in Djikstra’s famous let- these languages also include support for
ter “Go to considered harmful” [1968], parameterized types, polymorphic rou-
language designers have searched for tines (or classes), and exceptions. It is
more structured language features to not clear yet whether or not the current
handle cases where programmers for- focus on object-oriented languages will
merly used goto statements. One such eventually replace interest in more tra-
construct is the exception mechanism, ditional imperative languages.
which appeared in PL/I, Clu, and Ada, Meanwhile, there have been many in-
among others. Exceptions can be teresting developments in modern func-
“raised” either automatically by the sys- tional languages that provide support
tem (e.g., upon division by zero) or by for ADT’s, exceptions, and polymor-
the programmer (e.g., on an attempt to phism. Languages like ML [Milner et al.
pop an element off of an empty stack). 1990] and Haskell [Hudak and Fasel
As suggested by these examples, excep- 1992], for instance, are statically typed
tions are typically used to handle error and support implicit polymorphism.
conditions that arise in programming. Features in these languages like struc-
In many of these cases the currently tures, functors, and type classes provide
executing unit (e.g., the pop routine for a great deal of support for modular pro-
a stack) has no useful action that can be gramming. The Common Lisp Object
taken on detecting the error, but a call- System (CLOS) provides support for a
ing routing may. variant of object-oriented features
When an exception is raised, a search known as multi-methods, while a forth-
is made for an appropriate “handler.” If coming version of ML, ML 2000, will
a handler for the exception is found in almost certainly include support for ob-
the current activation unit, it is exe- jects.
cuted, otherwise the search for a handler The future of logic programming lan-
for the exception is made down the run- guages is not clear at the moment. After
time stack. That is, the search proceeds to a burst of interest in the early 1980s,
the unit that called the currently execut- they have settled into a fairly narrow
ing unit, and so on, until a handler is range of applications. More recent work
found. If no handler is found in the run- has focussed on replacing the “logic” in
time stack, the program halts. (A good these languages by the solution of con-
source of information on this and the straints [Benhamou and Colmerauer
other programming-language constructs 1993]. It is premature to say how impor-
discussed above is Louden [1993]). tant these languages will be in the long
More recently, more attention has run, but very interesting work is con-
been paid to object-oriented languages tinuing in this area.
like Smalltalk [Goldberg and Robson Languages are also playing an impor-
1983] and Eiffel [Meyer 1992] as well as tant role in the support of concurrency
to adding object-oriented features to and distributed computing. The key
older languages such as Pascal, C, Ada, ideas that must be supported are the
and even COBOL. As noted in this issue sharing of information and resources by
by Hirshfeld and Ege, object-oriented different processes and the need to en-
languages provide support for abstrac- sure the consistency of shared informa-
tions similar to that described above, tion across these processes. Languages
though from a somewhat different point can simply support primitive features to
of view. (Languages like Clu, Modula-2, fork off processes and synchronize them
and Ada-83 are sometimes called object- (e.g., using semaphores), or they can

ACM Computing Surveys, Vol. 28, No. 1, March 1996

 Progress in Programming Languages • 247

support more elaborate features like tion currently is on object-oriented lan-

monitors (Concurrent Pascal) or tasks guages, many of the more popular
(Ada). Interesting work is progressing languages either lack support for some
on concurrent object-oriented lan- of the important features mentioned
guages, which may provide finer control above, provide unsafe or excessively
over concurrency (especially with re- rigid type systems, or have extremely
gard to access to shared variables) in- complicated conceptual models. There is
side objects. Other approaches to con- some hope that, building on recent re-
currency rely on smart compilers being search in programming languages, the
able to detect and support concurrency next generation of object-oriented lan-
without programmer intervention. The guages will be both simpler and safer,
most popular of such approaches involve while taking advantage of the greater
imperative languages like FORTRAN support for modeling and reuse found in
(see the article by Wolfe in this issue), object-oriented languages. Certainly the
while others involve functional or data- emergence of languages like Java,
flow languages where there is less of an which provide platform-independent
obviously sequential flow of control support for programming with the abil-
within a program. At this point it is ity to download and execute programs
clear that programmer-controlled con- and libraries via capable web browsers,
currency is very difficult, but it is not at will have an important impact on both
all clear what the ultimate solution to programmers and users.
this difficulty will be. We may be witnessing the beginning
The articles about type systems by of a resurgence in languages that are
Cardelli and semantics by Schmidt in simple, safe, and high-level, yet are suf-
this issue highlight the importance of a ficiently powerful to provide efficient so-
more theoretically grounded study of lutions to real problems. One thing,
programming languages. Just as the however, is clear. We should not expect
syntax of a programming language can one language to provide the best solu-
be presented formally (e.g., as a context- tion to all problems. In particular, dif-
free grammar), the typing rules and se- ferent paradigms lead programmers to
mantics of a programming language can think in quite different ways. Which
also be presented using formal systems. language is most useful will likely de-
Given a precise formal presentation, it pend on the problem to be solved.
is possible to prove only that a type
system will successfully type-check pro-
grams without certain kinds of errors REFERENCES
and that rules for reasoning about pro-
grams are sound. BENHAMOU, F. AND COLMERAUER, A. EDS. 1993.
Constraint Logic Programming: Selected Re-
As an example of interesting develop- search. MIT Press, Cambridge, MA.
ments on the implementation of pro- DIJKSTRA, E. W. 1968. Goto statement consid-
gramming languages, improvements in ered harmful. Commun. ACM 11, 3, 147–148.
garbage-collection algorithms have led GOLDBERG, A. AND ROBSON, D. 1983. Smalltalk–
to better performance among functional 80: The Language and Its Implementation.
and object-oriented languages that rely Addison-Wesley, Reading, MA.
on automatic storage management HUDAK, P. AND FASEL, J. 1992. A gentle intro-
rather than requiring the programmer duction to Haskell. SIGPLAN Not. 27, 5 (May).
to worry about the error-prone activity LOUDEN, K. C. 1993. Programming Languages:
Principles and Practice. PWS, Boston, MA.
of manually disposing of heap-allocated
MEYER, B. 1992. Eiffel: The Language. Pren-
memory. tice-Hall, Englewood Cliffs, NJ.
We appear to be in a period of turmoil MILNER, R., TOFTE, M., AND HARPER,
in the choice of programming lan- R. 1990. The Definition of Standard ML.
guages. While the main focus of atten- MIT Press, Cambridge, MA.

ACM Computing Surveys, Vol. 28, No. 1, March 1996