Abstract. Forwarding is a technique for providing default attribute definitions in attribute grammars that is helpful in the modular implementation of programming languages. It complements existing techniques such as default copy rules. This paper introduces forwarding, and shows how it is but a small extension of standard higher-order attribute grammars. The usual tools for manipulating higher-order attribute grammars, including the circularity check (which tests for cyclic dependencies between attribute values), carry over without modification. The closure test (which checks that each attribute has a defining equation) needs modification, however, because the resulting higher-order attribute grammars may contain spurious attributes that are never evaluated, and indeed that need not be defined. 1

. Aspect-oriented programming provides the programmer with means to cross-cut conventional program structures, in particular the class hierarchies of object-oriented programming. This paper studies the use of aspect orientation in structuring syntax directed compilers implemented as attribute grammars. Specifically, it describes a method for specifying definitions of related attributes as `aspects' and treating them as first-class objects, that can be stored, manipulated and combined. It is hoped that this embedding of an aspect-oriented programming style in Haskell provides a stepping stone towards a more general study of the semantics of aspect-oriented programming. 1 Introduction Compilers are often structured by recursion over the abstract syntax of the source language. For each production in the abstract syntax, one defines a function that specifies how a construct is to be translated. The method of structuring compilers in this syntax--directed manner underlies the for...

We present a simple, practical algorithm for higher order matching in the context of automatic program transformation. Our algorithm finds more matches than the standard second order matching algorithm of Huet and Lang, but it has an equally simple specification, and it is better suited to the transformation of programs in modern programming languages such as Haskell or ML. The algorithm has been implemented as part of the MAG system for transforming functional programs. 1 Background and motivation 1.1 Program transformation Many program transformations are conveniently expressed as higher order rewrite rules. For example, consider the well-known transformation that turns a tail recursive function into an imperative loop. The pattern f x = if p x then g x else f (h x ) is rewritten to the term f x = j[ var r ; r := x ; while :(p r) do r := h r ; r := g r ; return r ]j Carefully consider the pattern in this rule: it involves two bound variables, namely f and x , and ...

this paper we honour Tony by building a simple model of structure editing to serve as a basis for the design of a family of editors. Structure editors make it easy to perform edit actions in which structural units (commands, expressions, chapters, paragraphs) are manipulated. Unfortunately these editors can make it rather difficult to enter certain kinds of new structure. For example, from the earliest days of structure editors for programming languages users have complained about awkwardness in entering expressions with infix operators. To illustrate this consider the expression

Programming languages and programming tasks are rarely a perfect fit: often a program could be much clarified by using a number of tailored language features...

ion Facilities . . . . . . . . . . . . . 55 4 Conclusion 56 4.1 Research Goals . . . . . . . . . . . . . . . . . . . . . . . . . . 56 4.1.1 Secondary Goals . . . . . . . . . . . . . . . . . . . . . 57 A Adding Exceptions to an Imperative Language 59 A.1 The Base Language . . . . . . . . . . . . . . . . . . . . . . . . 60 A.1.1 The Grammar . . . . . . . . . . . . . . . . . . . . . . . 60 A.1.2 Imperativelib.mli . . . . . . . . . . . . . . . . . . . 61 A.1.3 Imperativelib.ml . . . . . . . . . . . . . . . . . . . . 61 A.1.4 Internalname.mli . . . . . . . . . . . . . . . . . . . . 63 A.1.5 Internalname.ml . . . . . . . . . . . . . . . . . . . . . 63 A.1.6 compile.ml . . . . . . . . . . . . . . . . . . . . . . . . 64 4 A.1.7 Attribution Rules . . . . . . . . . . . . . . . . . . . . . 64 A.2 The Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 A.2.1 The Grammar Extensions . . . . . . . . . . . . . . . . 69 A.2.2 Attribution Rules . . . . . . . . . . . . . . . . . . . . . 7...

A domain-specific embedded language (DSEL) is a domain-specific programming language with no concrete syntax of its own. Defined as a set of combinators encapsulated in a module, it borrows the syntax and tools (such as type-checkers and compilers) of its host language; hence it is economical to design, introduce, and maintain. Unfortunately, this economy is counterbalanced by a lack of room for growth. DSELs cannot match sophisticated domain-specific languages that offer tools for domainspecific error-checking and optimisation. These tools are usually based on syntactic analyses, so they do not work on DSELs. Abstract interpretation is a technique ideally suited to the analysis of DSELs, due to its semantic, rather than syntactic, approach. It is based upon the observation that analysing a program is equivalent to evaluating it over an abstract semantic domain. The mathematical properties of the abstract domain are such that evaluation reduces to solving a mutually recursive set of equations. This thesis shows how abstract interpretation can be applied to a DSEL by replacing it with an abstract implementation