C is a general-purpose programming language. It has been closely associated with the UNIX operating system where it was developed, since both the system and most of the programs that run on it are written in C. The language, however, is not tied to any one operating system or machine; and although it has been called a ‘‘system programming language’’ because it is useful for writing compilers and operating systems, it has been used equally well to write major programs in many different domains. Many of the important ideas of C stem from the language BCPL, developed by Martin Richards. The influence of BCPL on C proceeded indirectly through the language B, which was written by Ken Thompson in 1970 for the first UNIX system on the DEC PDP-7. BCPL and B are ‘‘typeless’’ languages. By contrast, C provides a variety of data types. The fundamental types are characters, and integers and floating point numbers of several sizes. In addition, there is a hierarchy of derived data types created with pointers, arrays, structures and unions. Expressions are formed from operators and operands; any expression, including an assignment or a function call, can be a statement. Pointers provide for machine-independent address arithmetic. C provides the fundamental control-flow constructions required for well-structured programs: statement grouping, decision making (if-else), selecting one of a set of possible values (switch), looping with the termination test at the top (while, for) or at the bottom (do), and early loop exit (break). Functions may return values of basic types, structures, unions, or pointers. Any function may be called recursively. Local variables are typically ‘‘automatic’’, or created anew with each invocation. Function definitions may not be nested but variables may be declared in a block-structured fashion. The functions of a C program may exist in separate source files that are compiled separately. Variables may be internal to a function, external but known only within a single source file, or visible to the entire program.

. It is possible, but difficult, to reason in Hoare logic about programs which address and modify data structures defined by pointers. The challenge is to approach the simplicity of Hoare logic's treatment of variable assignment, where substitution affects only relevant assertion formul. The axiom of assignment to object components treats each component name as a pointerindexed array. This permits a formal treatment of inductively defined data structures in the heap but tends to produce instances of modified component mappings in arguments to inductively defined assertions. The major weapons against these troublesome mappings are assertions which describe spatial separation of data structures. Three example proofs are sketched. 1 Introduction The power of the Floyd/Hoare treatment of imperative programs [8][11] lies in its use of variable substitution to capture the semantics of assignment: simply, R E x , the result of replacing every free occurrence of variable x in R by...

The ease of understanding, maintaining, and developing a large program depends crucially on how it is divided up into modules. The possible ways a program can be divided are constrained by the available modular programming facilities ("module system") of the programming language being used. Experience with the Standard-ML module system has shown the usefulness of functions mapping modules to modules and modules with module subcomponents. For example, functions over modules permit abstract data types (ADTs) to be parameterized by other ADTs, and submodules permit modules to be organized hierarchically. Module systems with such facilities are called higher-order, by analogy with higher-order functions. Previous higher-order module systems can be classified as either opaque or transparent. Opaque systems totally obscure information about the identity of type components of modules, often resulting in overly abstract types. This loss of type identities precludes most interesting uses of hi...

With non-traditional application areas such as engineering design, image/voice data management, scientific/statistical applications, and artificial intelligence systems all clamoring for ways to store and efficiently process larger and larger volumes of data, it is clear that traditional database technology has been pushed to its lim-its. It also seems clear that no single database system will be capable of simultaneously meeting the functionality and performance requirements of such a diverse set of applications. In this paper we describe the initial design of EXODUS, an extensible database system that will facilitate the fast development of high-performance, application-specific database systems. EXODUS provides certain kernel facilities, including a versatile storage manager and a type manager. In addition, it provides an architectural framework for building application-specific database sys-tems, tools to partially automate the generation of such systems, and libraries of software components (e.g., access methods) that are likely to be useful for many application domains.

tee) cited Professor Floyd for "helping to found the following important subfields of computer science: the theory of parsing, the semantics of programming languages, automatic program verification, automatic program synthesis, and analysis of algo-rithms." Professor Floyd, who received both his A.B. and B.S. from the University of Chicago in 1953 and 1958, respectively, is a self-taught computer scientist. His study of computing began in 1956, when as a night-operator for an IBM 650, he found the time to learn about programming between loads of card hoppers. Floyd implemented one of the first Algol 60 compilers, finishing his work on this project in 1962. In the process, he did some early work on compiler optimization. Subsequently, in the

The syntax of comprehensions is very close to the syntax of a number of practical database query languages and is, we believe, a better starting point than first-order logic for the development of database languages. We give an informal account of a language based on comprehension syntax that deals uniformly with a variety of collection types; it also includes pattern matching, variant types and function definition. We show, again informally, how comprehension syntax is a natural fragment of structural recursion, a much more powerful programming paradigm for collection types. We also show that a very small "abstract syntax language" can serve as a basis for the implementation and optimization of comprehension syntax.

We discuss seven undesirable features common to many programming languages used to teach first-time programmers, and illustrate typical pedagogical difficulties which stem from them with examples drawn from the programming languages ABC, Ada, C, C++, Eiffel, Haskell, LISP, Modula 3, Pascal, Prolog, Scheme, and Turing. We propose seven language design (or selection) principles which may reduce the incidence of such undesirable features. Introduction Learning to program is difficult. We believe that a substantial part of this difficulty arises from the structure, syntax and semantics of the programming languages which are commonly used to teach programming. Programming language designers are (of necessity) highly intelligent experts in the field of programming, and are consequently far removed both temporally and cognitively from the difficulties experienced by the novice programmer. This gulf of experience and ability results in languages which are either too restrictive or too powerf...

The all-du-paths structural testing criterion is one of the most discriminating of the data flow testing criteria. Unfortunately, in the worst case, the criterion requires an intractable number of test cases. In a case study of an industrial software system, we find that the worst case scenario is rare. Eighty percent of the subroutines require ten or fewer test cases. Only one subroutine out of 143 requires an intractable number of tests. However, the number of required test cases becomes tractable when using the all-uses criterion. This paper includes a formal specification of both the all-du-paths criterion and the software tools used to estimate a minimal number of test cases necessary to meet the criterion. Keywords: Software testing, software measures formal specifications, data flow analysis. Department of Computer Science Technical Report #CS--91--105 Colorado State University (Revision of Technical Report #CS--89--118) A version of this paper was published in IEE/BCS Software Engineering Journal, 7(1):43-51, Jan. 1992. This research was partially supported by the NATO Collaborative Research Grants Program under RG. 0343/88. 1

Zusammenfassung Data Structures and Concepts for Adaptive Finite Element Methods. The administration of strongly nonuniform, adaptively generated finite element meshes requires specialized techniques and data structures. A special data structure of this kind is described in this paper. It relies on points, edges and triangles as basic structures and is especially well suited for the realization of iterative solvers like the hierarchical basis or the multilevel nodal basis method. AMS Subject Classifications: 65N50, 65Y99, 65N30, 65N55, 65F10 Key words: Data structures, adaptive finite element methods. Datenstrukturen und Strategien fur adaptive Finite Elemente. Fur die Verwaltung von extrem nichtuniformen, adaptiv erzeugten Finite Element Gittern benotigt man spezielle Techniken und Datenstrukturen. Eine Datenstruktur dieser Art wird in diesem Artikel beschrieben. Basisstrukturen sind Punkte, Kanten und Dreiecke. Die Datenstruktur ist besonders zugeschnitten auf iterative Loser wie die hierarchische Basis oder die "multilevel nodal basis" Methode. 1.

Currently database researchers are investigating new data models in order to remedy the deficiences of the flat relational model when applied to non-business applications. Herein we concentrate on a recent graph-based data model called the hypernode model. The single underlying data structure of this model is the hypernode which is a digraph with a unique defining label. We present in detail the three components of the model, namely its data structure, the hypernode, its query and update language, called HNQL, and its provision for enforcing integrity constraints. We first demonstrate that the said data model is a natural candidate for formalising hypertext. We then compare it with other graph-based data models and with set-based data models. We also investigate the expressive power of HNQL. Finally, using the hypernode model as a paradigm for graph-based data modelling, we show how to bridge the gap between graph-based and set-based data models, and at what computational cost this can...