Forty years ago development started on Mix, a partial evaluator designed specifically for the purpose of self-application. The effort, led by Neil D. Jones at the University of Copenhagen, eventually demonstrated that non-trivial compilers could be generated automatically by applying a partial evaluator to itself. The possibility, in theory, of such self-application had been known for more than a decade, but remained unrealized by the start of 1984. We describe the genesis of Mix, including the research environment, the challenges, and the main insights that led to success. We emphasize the critical role played by program annotation as a pre-processing step, later automated in the form of binding-time analysis.

Domain-specific languages (DSLs) have emerged as a plausible way for non-programming experts to efficiently express their domain knowledge. Recent DSL research has taken a technical perspective on how and why to create DSLs, resulting in a wealth of innovative tools, frameworks and technical approaches. Less attention has been paid to the design process. Namely, how can it ensure that the created DSL realises the expected benefits? This paper seeks to answer this question when designing DSLs for highly specialised domains subject to resource constraints, an evolving application domain, and scarce user participation. We propose an iteration of alternating activities in a human-centred design method that seeks to minimise the need for expensive implementation and user involvement. The method moves from a low-validity exploration of highly diverse language designs towards a higher-validity exploration of more homogeneous designs. We give an in-depth case study of designing an actuarial DSL called MAL, or Management Action Language, which allows actuaries to model so-called future management actions in asset/liability projections in life insurance and pension companies. The proposed human-centred design method was synthesised from this case study, where we found it useful for iteratively identifying and removing usability problems during the design.

Domain-specific languages seek to provide domain guarantees that eliminate many errors allowed by general-purpose languages. Still, a domain-specific language requires additional quality assurance measures to ensure that specifications behave as intended by the users. However, some domains may have specific quality assurance measures (e.g., proofs, experiments, or case studies) with little tradition of using quality assurance measures customary to software engineering. We investigate the possibility of accommodating such domains by conducting a workshop with 11 prospective users of a domain-specific language named MAL for the pension industry. The workshop emphasised the need for supporting actuaries with new analytical tools for quality assurance and resulted in three designs: quantity monitors let users identify outlier behaviour, fragment debugging lets users debug with limited evaluative power, and debugging spreadsheets let users visualise, analyse, and remodel concrete calculations with an established domain tool. Based on our experiences, we hypothesise that co-design workshops are a viable approach for DSLs in a similar situation.

We give an operational semantics for the evaluation of spreadsheets, including sheet-defined and built-in numeric functions in the Funcalc spreadsheet platform. The semantics allows for different implementations and we discuss sheet-defined functions implemented using both interpretation and run-time code generation. The semantics specifies the expected result of a computation, also considering non-deterministic functions, independently of an evaluation mechanism. It can be extended to include the cost of formula evaluation for a cost analysis e.g. for use in parallelization of computations. An interesting future direction is to investigate experimentally how close our semantics is to that of major spreadsheet implementations.

We give a simple but precise operational semantics for the evaluation of extended spreadsheet formulas, with array formulas, sheet-defined functions and closures, as found in the Funcalc spreadsheet platform [1]. We build on this to give a simple cost semantics, inspired by [2], for evaluation of a spreadsheet formula and for full and minimal recalculation of a spreadsheet. Following the ideas presented by Schmidt [3] we provide a big-step trace-based abstract interpretation for the cost semantics. We then present a set of functions which can be used to calculate the cost of executing an evaluation of a spreadsheet expression following Gomez et al. [4], inspired by Rosendahl [5]. These functions are related to the above operational semantics, cost semantics and abstract interpretation. The above semantic presentations all form the formal foundations for various cost calculations implemented in the Funcalc spreadsheet platform. These calculations are evaluated experimentally.

The specification of a programming language is a special case of the specification of software in general. This paper discusses the relation between semantics and implementation, or specification and program, using two very different languages for illustration. First, we consider small fragments of a specification of preliminary Ada, and show that what was considered a specification in VDM in 1980 now looks much like an implementation in a functional language. Also, we discuss how a formal specification may be valuable even though seen from a purely formal point of view it is flawed. Second, we consider the simple language of spreadsheet formulas and give a complete specification. We show that nondeterminism in the specification may reflect run-time nondeterminism, but also underspecification, that is, implementation-time design choices. Although specification nondeterminism may appear at different binding-times there is no conventional way to distinguish these. We also consider a cost semantics and find that the specification may need to contain some “artificial” nondeterminism for underspecification.

This chapter introduces the distinction between interpreters and compilers, and demonstrates some concepts of compilation, using the simple expression language as an example.

Spreadsheets are used heavily in industry and academia. Often, spreadsheet models are developed for years and their complexity grows vastly beyond what the paradigm was originally conceived for. Such complexity often comes at the cost of recalculation performance. However, spreadsheet models usually have some high-level structure that can be used to improve performance by performing independent computation in parallel. In this paper, we devise rules for rewriting high-level spreadsheet structure in the form of so-called cell arrays into higher-order functional programs that can be easily parallelized on multicore processors. We implement our rule set for the experimental Funcalc spreadsheet engine which already implements parallelizable higher-order array functions as well as user-defined higher-order functions. Benchmarks show that our rewriting approach improves recalculation performance for spreadsheets that are dominated by cell arrays.

We describe the quad rope data structure, a representation of immutable two-dimensional arrays that avoids many of the performance pitfalls of plain C-style two-dimensional arrays. Our motivation is that, for end-user development in high-level declarative programming languages, it is impractical to let users choose between different array-like data structures. Instead, one should use the same, somewhat performance-robust, representation for every programming task. Quad ropes roughly retain array efficiency, as long as programmers express their programs using high-level constructs. Moreover, they allow for fast concatenation and dynamic task-based parallelism and are well suited to represent sparse arrays. We describe their operational semantics and evaluate the performance of individual functions on quad ropes as well as declarative algorithms that use our quad rope implementation.

In Chap. 2 we considered a simple stack-based abstract machine for the evaluation of expressions with variables and variable bindings. Here we continue that work, and extend the abstract machine so that it can execute programs compiled from an imperative language (micro-C). We also write a compiler from the imperative programming language micro-C to this abstract machine.

InReal machine code|( Assembly code|( Chap. 8 we presented a compiler from micro-C to code for an abstract stack machine. In this chapter we describe real machine code in the form of assembly code for the x86 architecture, and show how to compile micro-C programs to such code. Executing micro-C programs translated into real machine code will be much faster, both because it avoids the interpretive overhead incurred by the abstract machine, and because it uses machine registers instead of the stack for expression evaluation.

Until now, we have written programs in abstract syntax, which is convenient when handling programs as data. However, programs are usually written in concrete syntax, as sequences of characters in a text file. So how do we get from concrete syntax to abstract syntax?

From the Publisher: Java Precisely provides a concise reference for the Java programming language and some of its essential libraries. The book covers Java 2, versions 1.3 and 1.4. It is intended both for students learning Java and for more experienced Java programmers. Though written informally, it describes the language in detail and provides many examples. To improve clarity, most of the general rules appear on left-hand pages with the relevant examples on the opposite right-hand pages.

The early development of compilers for high-level programming languages, and of so-called autocoding systems, is well documented at the international level but not as regards the Nordic countries.The goal of this paper is to provide a survey of compiler and autocode development in the Nordic countries in the early years, roughly 1953 to 1965, and to relate it to international developments. We also touch on some of the historical societal context.

Spreadsheets are heavily used in industry, because they are easily written and adjusted, using an intuitive visual interface. They often start out as simple tools; however, over time spreadsheets can become increasingly complex, up to the point where they become complicated and inflexible. In many ways, spreadsheet are similar to software: both concern the storage and manipulation of data and the presentation of results to the user. Because of this similarity, many methods and techniques from software engineering can be applied to spreadsheets. The role of SEMS, the International Workshop on Software Engineering Methods in Spreadsheets is to explore the possibilities of applying successful methods from software engineering to spreadsheets. Some, like testing and visualization, have been tried before and can be built upon. For methods that have not yet been tried on spreadsheets, SEMS will serve as a platform for early feedback. The SEMS program included an industrial keynote, "spreadsheet stories" (success or failure), short and long research papers, a good mix of industrial and academic researchers, as well as lively discussion and debate.