Modular structural operational semantics

ions Abstraction C COBOL Java Assembler Documentation Conversion Formalization Render PDF HTML GUI UML Generation Presentation Analysis Abstract syntax trees Facts in SQL tables GraphXML RSFsyntax trees Facts in SQL tables GraphXML RSF Figure 1.1: Three source code representation tiers and their (automated) transitions. to alter its behavior, but to improve non-functional quality attributes such as simplicity, flexibility and clarity. Software renovation [35] Reverse engineering is to analyze the source code of legacy software systems in order to retrieve their high-level design, and other relevant information. Re-engineering continues after reverse engineering, to adapt the derived abstractions to radically improve the functionality and non-functional quality attributes of a software system, after which an improved system will be derived. For any of the above areas it is interesting to maximize the number of tasks that are automated during the engineering processes. Automation of a task is expected to improve both efficiency of the task itself, and possibly also some quality attributes of the resulting software. Examples of such attributes are correctness and tractability: trivial inconsistencies made by humans are avoided and automated processes can be traced and repeated more easily than human activities. We use the term meta program to refer to programs that automate the manipulation of source code. Thus we call the construction of such programs meta programming. Many meta programs have been and will be developed to support the above engineering disciplines. Figure 1.1 sketches the domain, displaying all possible automated transitions from source code, via abstract representations, to documentation. Each of the above areas highlights and specializes a specific part of the graph in Figure 1.1. For example, reverse engineering is the path from source code, via several abstractions to documentation. In reverse engineering, extensive analysis of source code abstractions is common, but the other edges in the graph are usually not traversed. On the other hand, in model driven engineering we start from documentation, then formalize the documentation towards a more machine oriented description, before we generate actual source code. The example languages for each tier are meant to be indicative, but not restrictive. A specific language might assume the role of source code, abstraction or documentation depending on the viewpoint that is imposed by a particular software engineering task. Take for example a context-free grammar written in the EBNF language. It is source code, since we can generate a parser from it using a parser generator. It is also an abstraction, if we would have obtained it from analyzing a parser written in Java source code. It serves as documentation when a programmer tries to learn the syntax of a language from it.

/pdf/analysis-and-transformation-of-source-code-by-parsing-and-3ed7p5dkvm.pdf

Analysis and transformation of source code by parsing and rewriting

We show that time complexity analysis of higher-order functional programs can be effectively reduced to an arguably simpler (although computationally equivalent) verification problem, namely checking first-order inequalities for validity. This is done by giving an efficient inference algorithm for linear dependent types which, given a PCF term, produces in output both a linear dependent type and a cost expression for the term, together with a set of proof obligations. Actually, the output type judgement is derivable iff all proof obligations are valid. This, coupled with the already known relative completeness of linear dependent types, ensures that no information is lost, i.e., that there are no false positives or negatives. Moreover, the procedure reflects the difficulty of the original problem: simple PCF terms give rise to sets of proof obligations which are easy to solve. The latter can then be put in a format suitable for automatic or semi-automatic verification by external solvers. Ongoing experimental evaluation has produced encouraging results, which are briefly presented in the paper.

https://hal.inria.fr/hal-00909318/document

The geometry of types

Some data types are so simple that they tend to be reimplemented over and over again. This is certainly true for terms, tree-like data structures that can represent prefix formulae, syntax trees, intermediate code, and more. We first describe the motivation to introduce Annotated Terms (ATerms): unifying several term formats, optimizing storage requirements by introducing maximal subterm sharing, and providing a language-neutral exchange format. Next, we present a brief overview of the ATerm technology itself and of its wide range of applications. A discussion of competing technologies and the future of ATerms concludes the paper.

ATerms for manipulation and exchange of structured data: It's all about sharing

We consider distributed algorithms for solving a range of problems in a framework for trust in large-scale distributed systems. The framework is based on the notion of trust structures; a set of 'trust-levels' with two distinct partial orderings. In the trust model, a global trust-state is defined as the least fixed-point of a collection of local policies of nodes in the network. We show that it is possible to compute the global trust-state using a simple, robust and totally asynchronous distributed-algorithm. We also consider a distributed notion of proof-carrying-requests as a means of approximating the least fixed-point, enabling sound reasoning about the global trust-state without computing the exact fixed-point. Our proof-carrying-request model is different than the notion of proof-of-compliance from traditional trust-management; in particular, all proofs are efficiently verifiable or easily rejected, but, in the worst case, may require as much communication as computing the actual trust-state itself

Distributed Approximation of Fixed-Points in Trust Structures

Some basic programming constructs (e.g., conditional statements) are found in many different programming languages, and can often be included without change when a new language is designed. When writing a semantic description of a language, however, it is usually not possible to reuse parts of previous descriptions without change.This paper introduces a new Action Semantic Discription Formulation, ASDF, which has been designed specifically for giving reusable action semantic descriptions of individual language constructs. An initial case study in the use of ASDF has already provided reusable descriptions of all the basic constructs underlying Core ML.The paper also describes the Action Environment, a new environment supporting use and validation of ASDF descriptions. The Action Environment has been implemented on top of the ASF + SDF Meta-Environment, exploiting recent advances in techniques for integration of different formalisms, and inheriting all the main features of the Meta-Environment.

An Action Environment

Usually, the majority of language constructs found in a programming language can also be found in many other languages, because language design is based on reuse. This should be reflected in the way we give semantics to programming languages. It can be achieved by making a language description consist of a collection of modules, each defining a single language construct. The description of a single language construct should be language independent, so that it can be reused in other descriptions without any changes. We call a language description framework 'constructive' when it supports independent description of individual constructs. We present a case study in constructive semantic description. The case study is a description of Core ML, consisting of a mapping from it to BAS (Basic Abstract Syntax) and action semantic descriptions of the individual BAS constructs. The latter are written in ASDF (Action Semantics Definition Formalism), a formalism specially designed for writing action semantic descriptions of single language constructs. Tool support is provided by the ASF+SDF Meta-Environment and by the Action Environment, which is a new extension of the ASF+SDF Meta-Environment.

Constructive Action Semantics for Core ML

An action compiler targeting Standard ML

When writing semantic descriptions of programming languages, it is convenient to have tools for checking the descriptions. With frameworks that use inductively defined semantic functions to map programs to their denotations, we would like to check that the semantic functions result in denotations with certain properties. In this paper we present a type system for a modular style of the action semantic framework that, given signatures of all the semantic functions used in a semantic equation defining a semantic function, performs a soft type check on the action in the semantic equation. We introduce types for actions that describe different properties of the actions, like the type of data they expect and produce, whether they can fail or have side effects, etc. A type system for actions which uses these new action types is presented. Using the new action types in the signatures of semantic functions, the language describer can assert properties of semantic functions and have the assertions checked by an implementation of the type system. The type system has been implemented for use in connection with the recently developed formalism ASDF. The formalism supports writing language definitions by combining modules that describe single language constructs. This is possible due to the inherent modularity in ASDF. We show how we manage to preserve the modularity and still perform specialised type checks for each module.

/pdf/type-checking-semantic-functions-in-asdf-cijqbc0yms.pdf

Jørgen Iversen

Papers

An Action Environment

Constructive Action Semantics for Core ML

An action compiler targeting Standard ML

Type Checking Semantic Functions in ASDF

The Action Environment