A Haskell to Java Virtual Machine code compiler

Wakeling, David

doi:10.1007/bfb0055423

Cited by 7 publications

(8 citation statements)

References 4 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Our first attempts to compile lazy functional programs for the Java Virtual Machine showed that the cost of memory allocation could be a serious problem. We found that it was an order of magnitude higher in version 1.1 of the Sun Java Virtual Machine interpreter than in version 1.3 of the Hugs interpreter (Wakeling, 1997).…”

Section: The Cost Of Memory Allocationmentioning

confidence: 76%

Compiling lazy functional programs for the Java Virtual Machine

Wakeling

1999

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

In this paper, we show how lazy functional programs can be compiled for the Java Virtual Machine using a mapping between a version of the 〈v, G〉-machine and the Java Virtual Machine. This mapping is elegant – the description is entirely straightforward – and efficient – using it, both code size and execution speed are of the same order of magnitude as those obtained with a traditional functional language bytecode interpreter. In future, our work could serve as the basis of an interface between Haskell and Java.

show abstract

Section: The Cost Of Memory Allocationmentioning

confidence: 76%

Compiling lazy functional programs for the Java Virtual Machine

Wakeling

1999

J. Funct. Prog.

Self Cite

View full text Add to dashboard Cite

show abstract

“…The only other work we are aware of in this area is that of Wakeling, one based on the G-Machine [8], which translates the G-code produced by HBC (the Haskell compiler developed at Chalmers) into Java bytecode; and one based on the ν, G machine [7] which compiles a core language into a set of ν, G instructions which are then transformed in Java bytecode, again using HBC. Both versions use a separate class, and hence a separate file, for each function, rather than each program, as with our compiler.…”

Section: Results and Other Workmentioning

confidence: 99%

“…For instance, Java does bounds checking on array accesses, and that casts are legal whereas C does not, and both these operations occur frequently in our compiler. Wakeling [8] ascribed the poor performance of his compiler when compared to Hugs to the poor memory handling in the JVM, hypothesising that memory-allocation in Java is an order of magnitude more expensive than in Hugs. Functional programs certainly will create and destroy objects on a more frequent basis than an imperative object-oriented one -both primes and edigits creates something in the order of 500,000 App nodes and 130,000 Cons nodes, for example.…”

Section: Results and Other Workmentioning

confidence: 99%

“…We then discuss the design of the run-time environment of our compiler and how we compile Ginger programs. We give some results of running programs compiled with our compiler, comparing them with Nottingham and Yale Haskell interpreter Hugs [5], the Glasgow Haskell Compiler [6] and another lazy functional program compiler, developed by David Wakeling at Exeter, which targets the JVM [8,7], and finally conclude.…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Compiling lazy functional programs to Java bytecode

Meehan

Joy

1999

Softw: Pract. Exper.

View full text Add to dashboard Cite

The Java Virtual Machine (JVM) was designed as the target for Java compilers, but there is no reason why it cannot be used as the target for other languages. We describe the implementation of a compiler which translates a lazy, weakly-typed functional program into Java class files. We compare the performance of our compiler to the only other known compiler from a lazy functional language to the JVM. The results are broadly similar, suggesting that to get a significant performance speed-up using this compilation paradigm will come only from increasing the performance of the JVM, rather than enhancing the compiler itself.

show abstract

“…Despite problems mapping functional virtual machines onto these platforms various classes of functional language have taken this route, including sequential, concurrent, parallel, distributed and mobile languages. An early JVM-based sequential Haskell was produced by Wakeling (1997) and he has since produced a mobile Haskell (Wakeling, 1998). A JVM-based parallel Haskell similar to GpH has been implemented by Rauber du Bois (2001).…”

Section: Other Distributed Functional Languagesmentioning

confidence: 99%

Parallel and Distributed Haskells

2002

View full text Add to dashboard Cite

Parallel and distributed languages specify computations on multiple processors and have a computation language to describe the algorithm, i.e. what to compute, and a coordination language to describe how to organise the computations across the processors. Haskell has been used as the computation language for a wide variety of parallel and distributed languages, and this paper is a comprehensive survey of implemented languages. We outline parallel and distributed language concepts and classify Haskell extensions using them. Similar example programs are used to illustrate and contrast the coordination languages, and the comparison is facilitated by the common computation language. A lazy language is not an obvious choice for parallel or distributed computation, and we address the question of why Haskell is a common functional computation language.

show abstract

A Haskell to Java Virtual Machine code compiler

Cited by 7 publications

References 4 publications

Compiling lazy functional programs for the Java Virtual Machine

Compiling lazy functional programs for the Java Virtual Machine

Compiling lazy functional programs to Java bytecode

Parallel and Distributed Haskells

Contact Info

Product

Resources

About