Inductive-data-type Systems

In a previous work ("Abstract Data Type Systems", TCS 173(2), 1997), the last two authors presented a combined language made of a (strongly normalizing) algebraic rewrite system and a typed lambda-calculus enriched by pattern-matching definitions following a certain format, called the "General Schema", which generalizes the usual recursor definitions for natural numbers and similar "basic inductive types". This combined language was shown to be strongly normalizing. The purpose of this paper is to reformulate and extend the General Schema in order to make it easily extensible, to capture a more general class of inductive types, called "strictly positive", and to ease the strong normalization proof of the resulting system. This result provides a computation model for the combination of an algebraic specification language based on abstract data types and of a strongly typed functional language with strictly positive inductive types.Comment: Theoretical Computer Science (2002

Designing a commutative replicated data type

Commuting operations greatly simplify consistency in distributed systems. This paper focuses on designing for commutativity, a topic neglected previously. We show that the replicas of \emph{any} data type for which concurrent operations commute converges to a correct value, under some simple and standard assumptions. We also show that such a data type supports transactions with very low cost. We identify a number of approaches and techniques to ensure commutativity. We re-use some existing ideas (non-destructive updates coupled with invariant identification), but propose a much more efficient implementation. Furthermore, we propose a new technique, background consensus. We illustrate these ideas with a shared edit buffer data type

On the Use of Underspecified Data-Type Semantics for Type Safety in Low-Level Code

In recent projects on operating-system verification, C and C++ data types are often formalized using a semantics that does not fully specify the precise byte encoding of objects. It is well-known that such an underspecified data-type semantics can be used to detect certain kinds of type errors. In general, however, underspecified data-type semantics are unsound: they assign well-defined meaning to programs that have undefined behavior according to the C and C++ language standards. A precise characterization of the type-correctness properties that can be enforced with underspecified data-type semantics is still missing. In this paper, we identify strengths and weaknesses of underspecified data-type semantics for ensuring type safety of low-level systems code. We prove sufficient conditions to detect certain classes of type errors and, finally, identify a trade-off between the complexity of underspecified data-type semantics and their type-checking capabilities.Comment: In Proceedings SSV 2012, arXiv:1211.587

Improving a data-acquisition software system with abstract data type components

Abstract data types and object-oriented design are active research areas in computer science and software engineering. Much of the interest is aimed at new software development. Abstract data type packages developed for a discontinued software project were used to improve a real-time data-acquisition system under maintenance. The result saved effort and contributed to a significant improvement in the performance, maintainability, and reliability of the Goldstone Solar System Radar Data Acquisition System

Multicomputer communication system

A local area network is provided for a plurality of autonomous computers which operate at different rates and under different protocols coupled by network bus adapters to a global bus. A host computer (HC) divides a message file to be transmitted into blocks, each with a header that includes a data type identifier and a trailer. The associated network bus adapter (NBA) then divides the data into packets, each with a header to which a transport header and trailer is added with frame type code which specifies one of three modes of addressing in the transmission of data, namely a physical address mode for computer to computer transmission using two bytes for source and destination addresses, a logical address mode and a data type mode. In the logical address mode, one of the two addressing bytes contains a logical channel number (LCN) established between the transmitting and one or more receiving computers. In the data type mode, one of the addressing bytes contains a code identifying the type of data

Categorical aspects of data type constructors

AbstractSketches are introduced as presentations of many-sorted algebraic theories and data types are described as initial algebras for such sketches. A construction A+ofB is described where A+ is a suitably structured sketch and B is a sketch. In this construction each operation from A+ operates on all the sorts of B. Many examples are given. The two main theoretical results are the theorem about the tensor product ⊗ for structured sketches such that A+of(B+of C)≃(A+⊗B+)of C (Theorem 3.17), and the “homomorphism” theorem 4.2 which describes the operation of structured sketches on the fibred category of all models of all sketches