The CIL compiler for core Standard ML compiles whole ML programs using a novel typed intermediate language that supports the generation of type-safe customized data representations. In this paper, we present empirical data comparing the relative efficacy of several different flow-based customization strategies for function representations. We develop a cost model to interpret dynamic counts of operations required for each strategy. In this cost model, customizing the representation of closed functions gives a 12–17 % improvement on average over uniform closure representations, depending on the layout of the closure. We also present data on the relative effectiveness of various strategies for reducing representation pollution, i.e., situations where flow constraints require the representation of a value to be less efficient than it would be in ideal circumstances. For the benchmarks tested and the types of representation pollution detected by our compiler, the pollution removal strategies we consider often cost more in overhead than they gain via enabled customizations. Notable exceptions are selective defunctionalization, a function representation strategy that often achieves significant customization benefits via aggressive pollution removal, and a simple form of flow-directed inlining, in which pollution removal allows multiple functions to be inlined at the same call site.

Abstract Many functions have to be written over and over again for different datatypes, either because datatypes change during the development of programs, or because functions with similar functionality are needed on different datatypes. Examples of such functions are pretty printers, pattern matchers, equality functions, unifiers, rewriting functions, etc. Such functions are called polytypic functions. A polytypic function is a function that is defined by induction on the structure of user-defined datatypes. This thesis introduces polytypic functions, shows how to construct and reason about polytypic functions and describes the implementation of the polytypic programming system PolyP. PolyP extends a functional language (a subset of Haskell) with a construct for writing polytypic functions. The extended language type checks definitions of polytypic functions, and infers the types of all other expressions. Programs in the extended language are translated to Haskell.

This paper illustrates how Haskell's type class system can be used to express computations. Since computations on the type level are performed by the type checker, these computations are static (i.e., performed at compile-time), and, since the type system is decidable, they always terminate. Haskell thus provides a means to express static computations, and has a clear distinction between static and dynamic computations. Instance declarations dene predicates over types, or in the case of multi-parameter classes, relations between types. With functional dependencies, multi-parameter classes directly specify functions, and thanks to them you can get the type checker to compute the values of function applications, rather than just checking that the result of an application is what you say it is. This way of expressing computation gives us the power of a small, rst-order functional programming language, with pattern matching and structural recursion. We can easily dene things like booleans, natural numbers, lists, and functions over these types. We give some examples of completely static computations, the most elaborate one being an implementation of insertion sort. We also give examples where static and dynamic computations are mixed. 1

Optimizing compilers for function-oriented and object-oriented languages exploit type and flow information for efficient implementation. Although type and flow information (both control and data flow) are inseparably intertwined, compilers usually compute and represent them separately. Partially, this has been a result of the usual polymorphic type systems using 8 and 9 quantifiers, which are difficult to use in combination with flow annotations. In the Church Project, we are experimenting with intermediate languages that integrate type and flow information into a single flow type framework. This integration facilitates the preservation of flow and type information through program transformations. In this paper we describe CIL, an intermediate language supporting polymorphic types and polyvariant flow information and describe its application in program optimiziation. We are experimenting with this intermediate language in a flow and typedirected compiler for a functional language. ...

. Polymorphic equality is a controversial language construct. While being convenient for the programmer, it has been argued that polymorphic equality (1) invites to violation of software engineering principles, (2) lays a serious burden on the language implementor, and (3) enforces a runtime overhead due to the necessity of tagging values at runtime. We show that neither (2) nor (3) are inherent to polymorphic equality by showing that one can compile programs with polymorphic equality into programs without polymorphic equality in such a way that there is no need for tagging or for runtime type analysis. Also, the translation is the identity on programs that do not use polymorphic equality. Experimental results indicate that even for programs that use polymorphic equality, the translation gives good results. 1 Introduction Often, statically typed languages, like ML, provide the programmer with a generic function for checking structural equality of two values of the same type. To avoid ...

Polymorphic recursion is a useful extension of Hindley-Milner typing and has been incorporated in the functional programming language Haskell. It allows the expression of efficient algorithms that take advantage of non-uniform data structures and provides key support for generic programming. However, polymorphic recursion is, perhaps, not as broadly understood as it could be and this, in part, motivates the denotational semantics presented here. The semantics reported here also contributes an essential building block to any semantics of Haskell: a model for first-order polymorphic recursion. Furthermore, Haskell-style type classes may be described within this semantic framework in a straightforward and intuitively appealing manner.

This document can be represented by the datatype Html4 as follows: my_html :: Html4 ParType my_html = List [ Heading (HeadingPar 1) (Text (TextPar "My Home Page")) , HRule , Break , Heading (HeadingPar 2) (Text (TextPar "Links to my friends:")) , List [ Link (UrlPar "http://...martijn...") (Text (TextPar "Martijn")) , Link (UrlPar "http://...michiel...") (Text (TextPar "Jantje")) ] ] To compress my_html using the strategy described above, its shape and data must be separated. The data can be obtained by attening, it is a list of values of type ParType: [ HeadingPar 1 , TextPar "My Home Page" , HeadingPar 2 , TextPar "Links to my friends:" , UrlPar "http://...martijn..." , TextPar "Martijn" , UrlPar "http://..jantje..." , TextPar "Jantje" ] The shape of my_html is obtained by replacing each datum by (), i.e. by leaving out the data. Since all data is declared as a parameter, the shape consists of just constructors. The rst step in shape compression is attening the shape to a list of constructors. Here is a representation of the attened shape of my_html: [ List, Cons, Heading, Text , Cons, HRule , Cons, Break , Cons, Heading, Text , Cons, List, Cons, Link, Text , Cons, Link, Text , Nil , Nil ] The list is formatted such that the represented structure is still visible. Since all datatypes in Haskell are sum-of-product datatypes, all datatypes in PolyP are sum-of-product datatypes too. The constructors of any datatype in PolyP can therefore be coded as natural numbers indicating which injection into the sum each constructor represents. These numbers are easily retrieved by inspecting the data declaration of a given datatype. We call such a number the

In this paper we demonstrate how to relate the semantics given by the nondeterministic call-by-need calculus FUNDIO [SS03] to Haskell. After introducing new correct program transformations for FUNDIO, we translate the core language used in the Glasgow Haskell Compiler into the FUNDIO language, where the IO construct of FUNDIO corresponds to direct-call IO-actions in Haskell. We sketch the investigations of [Sab03b] where a lot of program transformations performed by the compiler have been shown to be correct w.r.t. the FUNDIO semantics. This enabled us to achieve a FUNDIO-compatible Haskell-compiler, by turning off not yet investigated transformations and the small set of incompatible transformations. With this compiler, Haskell programs which use the extension unsafePerformIO

The CIL compiler for core Standard ML compiles whole ML programs using a novel typed intermediate language that supports the generation of type-safe customized data representations. In this paper, we present empirical data comparing the relative efficacy of several different customization strategies for function representations. We develop a cost model to interpret dynamic counts of operations required for each strategy. One of our results is data showing that compiling with a function representation strategy that makes customization decisions based on the presence or absence of free variables of a function and which removes representation pollution by introducing multiway dispatch (what we call the selective sink splitting strategy) can produce better code than that produced by a defunctionalizing strategy similar to that in the literature [5, 35, 8].

The combination of intersection and union types with ow types gives the compiler writer unprecedented exibility in choosing data representations in the context of a typed intermediate language. We present the design of such a language and the design of a framework for exploiting the type system to support multiple representations of the same data type in a single program. The framework can transform the input term, in a type-safe way, so that dierent data representations can be used in the transformed term | even if they share a use site in the pre-transformed term. We have implemented a compiler using the typed intermediate language and instantiated the framework to allow specialized function representations. We test the compiler on a set of benchmarks and show that the compile-time performance is reasonable. We further show that the compiled code does indeed bene t from specialized function representations.