Syntax Tree (AST), where the DCLs correspond to the productions of the syntax of some programming language. This would be misleading, however, because there is no syntax and there are no productions. The DCL corresponds only to what the programmer had I am indebted to Dr. Hendrik Boom for the term. in mind, it corresponds to an intention. But to understand precisely the distinction, we have to take a few more steps to complete the definition. To make an intention actionable, we associate with the DCL a method which describes the semantics of the intention by specifying the process of transforming the subtree headed by the intention instance into a tree containing only primitive executable nodes with fixed semantics. Now to obtain a runnable program, we need only traverse the intentional tree and apply the transformations indicated by the DCLs pointed to by the nodes, in a process we term "reduction". To distinguish the transforming method from traditional object oriented methods which are to be invoked in run time, the term "extension method" or xmethod will be used. The tree containing only primitive executable nodes will be called "reduced tree" which is written in a fixed language called "R-code". The transformations can be whimsically called "reduction enzymes". The reduced tree is really an intermediate language for interfacing with a machine-specific code generator. The reason that we use trees for this purpose is purely an engineering decision: since reduction enzymes must already operate on trees which are their inputs, it is only natural that their outputs be in the same form also. To be sure, the reduction need not take place in a single step, so the above description is somewhat simplified. A node may be transformed several times until the subtree is comple...

How should iterators be abstracted and encapsulated in modern imperative languages, e.g., Ada and C++? We consider the combined impact of several factors on this question: the need for a "common interface model" for userdefined iterator abstractions; the importance of formal methods in specifying such a model; and problems involved in modular correctness proofs of iterator implementations and clients. A series of iterator designs illustrates the advantages of the "swapping paradigm" over designs based on the traditional "copying paradigm." Specifically, swapping-based designs admit more efficient implementations, while offering straightforward formal specifications and the potential for modular reasoning about program behavior. The final proposed design schema defines a common interface model for iterators for a wide variety of generic collection abstractions in languages such as Ada and C++. Index Terms --- Formal specification, iterator, program verification, proof of correctness, sw...

this paper is organized as a derivation of Intentional Programming (IP) from first principles, it must be obvious to anyone with practical scientific experience that the historical development of IP followed a heuristic, pragmatic and iterative path, and the present logic has been reverse engineered from the results of this development for pedagogical clarity. Indeed, the pedagogical purpose is only enhanced if the pretense were lifted and the list were taken to be a description, as well as a motivation for IP. The "unassailable" items will form the basis for IP and indicate the emphasis; the "doubtful" items will be all delegated back to the users for routine resolution, and the "terrible things" will all find solutions