Transformational derivation of programs using the Focus system

A program derivation support system called Focus is being constructed. It will formally derive programs using the paradigm of program transformation. The following issues are discussed: (1) the integration of validation and program derivation activities in the Focus system; (2) its tree-based user interface; (3) the control of search spaces in program derivation; and (4) the structure and organization of program derivation records. The inference procedures of the system are based on the integration of functional and logic programming principles. This brings about a synthesis of paradigms that were heretofore considered far apart, such as logical and executable specifications and constructive and transformational approaches to program derivation. A great emphasis has been placed, in the design of Focus, on achieving small search spaces during program derivation. The program manipulation operations such as expansion, simplification and rewriting were designed with this objective. The role of operations that are expensive in search spaces, such as folding, has been reduced. Program derivations are documented in Focus in a way that the high level descriptions of derivations are expressed only using program level information. All the meta-level information, together with dependencies between derivations of program components, is automatically recorded by the system at a lower level of description for its own use in replay

Building an IDE for the Calculational Derivation of Imperative Programs

In this paper, we describe an IDE called CAPS (Calculational Assistant for Programming from Specifications) for the interactive, calculational derivation of imperative programs. In building CAPS, our aim has been to make the IDE accessible to non-experts while retaining the overall flavor of the pen-and-paper calculational style. We discuss the overall architecture of the CAPS system, the main features of the IDE, the GUI design, and the trade-offs involved.Comment: In Proceedings F-IDE 2015, arXiv:1508.0338

A static analysis for quantifying information flow in a simple imperative language

We propose an approach to quantify interference in a simple imperative language that includes a looping construct. In this paper we focus on a particular case of this definition of interference: leakage of information from private variables to public ones via a Trojan Horse attack. We quantify leakage in terms of Shannon's information theory and we motivate our definition by proving a result relating this definition of leakage and the classical notion of programming language interference. The major contribution of the paper is a quantitative static analysis based on this definition for such a language. The analysis uses some non-trivial information theory results like Fano's inequality and L1 inequalities to provide reasonable bounds for conditional statements. While-loops are handled by integrating a qualitative flow-sensitive dependency analysis into the quantitative analysis

Introduction

This chapter will motivate why it is useful to consider the topic of derivations and filtering in more detail. We will argue against the popular belief that the minimalist program and optimality theory are incompatible theories in that the former places the explanatory burden on the generative device (the computational system) whereas the latter places it on the fi ltering device (the OT evaluator). Although this belief may be correct in as far as it describes existing tendencies, we will argue that minimalist and optimality theoretic approaches normally adopt more or less the same global architecture of grammar: both assume that a generator defines a set S of potentially well-formed expressions that can be generated on the basis of a given input and that there is an evaluator that selects the expressions from S that are actually grammatical in a given language L. For this reason, we believe that it has a high priority to investigate the role of the two components in more detail in the hope that this will provide a better understanding of the differences and similarities between the two approaches. We will conclude this introduction with a brief review of the studies collected in this book.

Classes of Terminating Logic Programs

Termination of logic programs depends critically on the selection rule, i.e. the rule that determines which atom is selected in each resolution step. In this article, we classify programs (and queries) according to the selection rules for which they terminate. This is a survey and unified view on different approaches in the literature. For each class, we present a sufficient, for most classes even necessary, criterion for determining that a program is in that class. We study six classes: a program strongly terminates if it terminates for all selection rules; a program input terminates if it terminates for selection rules which only select atoms that are sufficiently instantiated in their input positions, so that these arguments do not get instantiated any further by the unification; a program local delay terminates if it terminates for local selection rules which only select atoms that are bounded w.r.t. an appropriate level mapping; a program left-terminates if it terminates for the usual left-to-right selection rule; a program exists-terminates if there exists a selection rule for which it terminates; finally, a program has bounded nondeterminism if it only has finitely many refutations. We propose a semantics-preserving transformation from programs with bounded nondeterminism into strongly terminating programs. Moreover, by unifying different formalisms and making appropriate assumptions, we are able to establish a formal hierarchy between the different classes.Comment: 50 pages. The following mistake was corrected: In figure 5, the first clause for insert was insert([],X,[X]

The “Integrative Justice Model” as Transformative Justice for Base-of-the-Pyramid Marketing

Writing in Business and Politics, Santos and Laczniak (Business and Politics 14(1) 2012) formulated a normative, ethical approach to be followed when marketers e ngage impoverished market segments. It is labeled the integrative justice model (IJM). As noted below, that approach called for authentic engagement, co-creation, and customer interest representation, among other elements, when transacting with vulnerable market segments. Basically, the IJM derived certain operational virtues, implied by moral philosophy, to be used when marketing to the poor. But this well-intentioned approach raises a significant “So what?” question. Are such sentiments anything but lofty aspirations for idealists or are there steps to be taken by society and business managers of goodwill to make the adaptation of the IJM by corporations more likely and pragmatic? This paper begins to layout a roadmap that shows “how and why” the IJM might more likely be vitalized. The crux, as described below, is found in the transformational justice dimensions that are embedded in institutions (and supporting institutional arrangements); such external institutions provide a “power” impetus to assure the ethical rights claims that impoverished consumers have owed to them. In this way, the ideal exchange characteristics for bottom (or base) of the pyramid (BoP) markets argued for in the IJM can become actively transformational. The main contribution of this paper is that it begins to chart out the institutional system elements that need to exercise power in order to deliver a “fairer” marketplace for BoP consumers

Assessing Learning-Centered Leadership: Connections to Research, Professional Standards, and Current Practices

Describes an assessment model designed to evaluate school leaders' performance. Unlike existing tools, this new system will assess both individuals and teams, and focuses specifically on instructional leadership and behaviors that improve learning

Transformational maintenance by reuse of design histories

This thesis provides theory and procedures for modifying software artifacts implemented by a formal transformation process. Installing modifications requires knowing not only what transformations were applied (a derivation history) to construct the artifact, but also why the application sequence ensures that the artifact meets its specification. The derivation history and the justification are collectively called a design history. A Design Maintenance System (DMS), when provided with a formal change called a maintenance delta, revises a design history to guide construction of a new artifact. A DMS can be used to integrate a stream of deltas into a history, providing implementations as a side effect, leading to an incremental-evolution model for software construction.We provide a broadly applicable formal model of transformation systems in which specifications are performance predicates, subsuming the functional specifications which are traditional for transformation systems. Such performance predicates provide vocabulary used in the design history to describe the effect of applying sets of transformations.A nonprocedural, performance-goal-oriented Transformation Control Language (TCL) is defined to control navigation of the design space for a transformation system. Recording the execution of a TCL metaprogram directly provides a design history.A complete classification of, and representation for, the set of possible maintenance deltas is given in terms of the inputs defined by the transformation system model. Such deltas include not only specification changes, but also changes to implementation support technologies. Delta integration procedures for revising derivation histories given functional or support technology deltas are provided, based on rearranging the order of transformations in the design space. Building on these operations, integration procedures that revise the design history for each type of delta are described. An agenda-oriented TCL execution process dovetails smoothly with the integration procedures.Our DMS is compared to a number of other maintenance systems. By using an explicit delta and verified commutativity, our DMS often reuses transformations correctly when others fail

USTOPIA REQUIREMENTS THOUGHTS ON A USER-FRIENDLY SYSTEM FOR TRANSFORMATION OF PROGRAMS IN ABSTRACTO

Transformational programming is a program development method which is usually applied using 'pen and paper'. Since this requires a lot of clerical work (copying expressions, con- sistent substitution) which is tiresome and prone to error, some form of machine support is desirable. In this paper a number of systems are described that have already been built to this aim. Some of their shortcomings and limitations are identified. Based on experience with program transformation and transformation systems, a long list of features is given that would be useful in an 'utopian' transformation system. This list is presented using an orthogonal division of the problem area. A number of problems with the realisation of some aspects of our 'utopian' system are identified, and some areas for further research are indicated