Citation Context

.... In this work certain named functions are automatically fused together. By rewriting library functions in terms of these special functions, fusion occurs. Whole Program Compilation The GRIN approach =-=[1]-=- uses whole program compilation for Haskell. It is currently being implemented in the jhc compiler [12], with promising initial results. GRIN works by first translating Haskell into a monadic intermed...

Citation Context

...ression-based, purely functional form to a statement-based, imperative one. Although a number of compilers have compiled Haskell by transformation to a strict language with explicitly lazy constructs =-=[5, 6, 11, 12]-=-, currently GHC instead relies on specialized runtime system support for laziness [27]. Demonstrating that our minimalist runtime system is adequate to run Haskell programs is an important step toward...

Citation Context

...eliability and feature richness: UHC itself uses GHC as its main development tool. Recently, JHC [27] and LHC [18] (derived from JHC) also take the whole-program analysis approach proposed by Boquist =-=[8, 7]-=- as their starting point. LHC in its most recent incarnation is available as a backend to GHC, and thus is not a standalone Haskell compiler. Already longer available alongside GHC are Hugs [21] which...

Citation Context

...pruning it is necessary to know for each closure what its possible tags are. This is to be determined by a global control flow analysis. Boquist sketches an algorithm for this abstract interpretation =-=[4]-=-. Here we present a full implementation we employ in our experimental Haskell compiler [6]. Algorithms are often described in some mathematical formalism. A problem of mathematical notation is that it...

Citation Context

...ur main motivation for proposing explicit update markers for pure functional languges was our desire to write idiomatic functional code even in the presence of destructive updates. In a lazy setting, besides retaining a functional style of programming, we also want to keep referential transparency, so that reasoning about programs remains manageable. Obviously, maintaining referential transparency in the presence of destructive updates is far from trivial. Consider, for example, the following program: let l = [1 . . 10] in filter odd l ++ filter even l. One would expect it to produce the list [1, 3, 5, 7, 9, 2, 4, 6, 8, 10]— and so it does. However, if we replace the calls to the standard filter function by calls to a version that reuses parts of the spine of its input list to produce its output, filter• p l@[ ] = l filter• p l@(x : xs) |p x = l@(x : filter• p xs) |otherwise = filter• p xs, we actually end up with the list [1, 3, 5, 7, 9], because the second invocation of filter• is then bound to traverse a list that contains nothing but odd numbers. In general, such referential opaqueness renders reasoning about programs a tedious undertaking. So, to be able to use update markers without giving up referential t...

Citation Context

...gister allocation on the entire program at once and precede it with a data flow analysis to estimate how function argument and suspended computations drift from construction site to consumption sites =-=[BJ96]-=-. Based on the observation that many Lisp programs spend most of their time in the bottom of the call graph, Steenkiste and Hennessy have developed the bottom up register allocation [SH89, Ste91]. Thi...

Citation Context

...is. Various analysis methods have been proposed to reduce the size of the apply function, by statically determining a safe subset of the possible functional values at a call site (Cejtin et al. 2000; =-=Boquist and Johnsson 1996-=-). Reynolds’ method has been used as a tool in program calculation (Danvy and Nielsen 2001; Hutton and Wright 2006), often as a mechanism for removing introduced continuations. Another use of Reynolds...

Citation Context

...braries from defunctionalized Haskell code, provided that defunctionalization interfaces are distributed together with object files; such libraries can then be used by any third-party source code that has an appropriate linker. 6 Related Work Pottier and Gauthier point out that defunctionalization can be modular for languages that are richer than our HLM and support recursive multi-methods [14]. Our technique is simpler, as it only records closure constructor information for every module. GRIN’s front-end had some support for separate compilation, but the back-end was a whole-program compiler [5]. The Utrecht Haskell Compiler (UHC), which is also based on the GRIN approach, supports separate compilation for a special bytecode format that runs on an interpreter but not for native code [10]. In the context of the specialization transformation in UHC, Middelkoop pointed out that to fully support separate compilation in the presence of defunctionalization, some information should be kept that looks like the abstract syntax tree of a function [12]. We do the same by keeping only closure constructor type information, which is enough to generate the final abstract syntax tree of the required...