this paper we will assume the availablity of a set of parsing combinators, that enables us to coinstruct such a mapping almost without e#ort.

. 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...

In this paper we consider the problem of decorating trees. We examine the special case where multiple traversals over a tree are needed for full decoration. We compare three functional approaches that do not recompute any values in successive traversals: a circular program to short-circuit multiple passes, a program with bindings from one traversal to the next to explicitly pass values and finally a monadic program that records a suitable state. Given our criteria, avoiding lazy evaluation and the ability to memoize the traversals, bindings seem to have the most advantages. 1 Introduction This paper discusses a special form of tree decorations that requires multiple traversals over a tree. Multiple traversals are needed if "global" information must first be gathered before it can be used: information flows from one traversal to the next. Tree decoration in imperative programming is straightforward: attributes are stored in the tree. Therefore, no complications arise when a later trave...

Syntax . . . . . . . . . . . . . . . 86 5.4.2 Pretty Printing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89 5.4.3 Typing and Type Checking . . . . . . . . . . . . . . . . . . . . . . . . 90 5.4.4 Environment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 5.4.5 Label Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95 5.4.6 Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96 6 Type Systems 107 6.1 Why typing? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.1.1 Avoiding run-time errors . . . . . . . . . . . . . . . . . . . . . . . . . . 107 6.1.2 E#ciency of code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 6.1.3 E#ciency of Development . . . . . . . . . . . . . . . . . . . . . . . . . 110 6.2 Type Checking versus Type Inferencing . . . . . . . . . . . . . . . . . . . . . 110 6.3 Type Language . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.3.1 Basic Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111 6.3.2 Composite Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112 6.4 Type Inferencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.4.1 Type Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113 6.4.2 Type derivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115 6.5 Polymorphism . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117 6.5.1 Substitution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118 6.5.2 Unification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119 6.5.3 Type Rules For Polymorphism . . . . . . . . . . . . . . . . . . . . ...

Circular functional programs (necessarily evaluated lazily) have been used as algorithmic tools, as attribute grammar implementations, and as target for program transformation techniques. Classically, Richard Bird [1984] showed how to transform certain multitraversal programs (which could be evaluated strictly or lazily) into one-traversal ones using circular bindings. Can we go the other way, even for programs that are not in the image of his technique? That is the question we pursue in this paper. We develop an approach that on the one hand lets us deal with typical examples corresponding to attribute grammars, but on the other hand also helps to derive new algorithms for problems not previously in reach.