Results 1 -
4 of
4
The Marriage of Effects and Monads
, 1998
"... this paper is to marry effects to monads, writing T for a computation that yields a value in and may have effects delimited by oe. Now we have that ( is ..."
Abstract
-
Cited by 75 (3 self)
- Add to MetaCart
this paper is to marry effects to monads, writing T for a computation that yields a value in and may have effects delimited by oe. Now we have that ( is
Bridging the gulf: a common intermediate language for ML and Haskell
- In ACM Symposium on Principles of Programming Languages
, 1998
"... Compilers for ML and Haskell use intermediate languages that incorporate deeply-embedded assumptions about order of evaluation and side effects. We propose an intermediate language into which one can compile both ML and Haskell, thereby facilitating the sharing of ideas and infrastructure, and suppo ..."
Abstract
-
Cited by 19 (2 self)
- Add to MetaCart
Compilers for ML and Haskell use intermediate languages that incorporate deeply-embedded assumptions about order of evaluation and side effects. We propose an intermediate language into which one can compile both ML and Haskell, thereby facilitating the sharing of ideas and infrastructure, and supporting language developments that move each language in the direction of the other. Achieving this goal without compromising the ability to compile as good code as a more direct route turned out to be much more subtle than we expected. We address this challenge using monads and unpointed types, identify two alternative language designs, and explore the choices they embody. 1 Introduction Functional programmers are typically split into two camps: the strict (or call-by-value) camp, and the lazy (or call-byneed) camp. As the discipline has matured, though, each camp has come more and more to recognise the merits of the other, and to recognise the huge areas of common interest. It is hard, thes...
Mobile Haskell: Compiling Lazy Functional Programs for the Java Virtual Machine
- PLILP | International Symposium on Programming Languages, Implementations, Logics and Programs. (p
, 1998
"... . This paper shows how lazy functional programs can be made mobile by compiling them for the Java Virtual Machine. The Haskell compiler it describes is based on the h,Gi-machine, which is designed for implementing lazy functional languages on parallel processors. Although this is not the obvious thi ..."
Abstract
-
Cited by 7 (0 self)
- Add to MetaCart
. This paper shows how lazy functional programs can be made mobile by compiling them for the Java Virtual Machine. The Haskell compiler it describes is based on the h,Gi-machine, which is designed for implementing lazy functional languages on parallel processors. Although this is not the obvious thing to do, it leads to a particularly elegant set of translation rules. Sadly though, the speed of the resulting Java Virtual Machine code programs is disappointing due to the surprisingly high cost of memory allocation/reclamation in current implementations of the Java Virtual Machine. In future work, we intend to find out whether this high cost is a property of the Java Virtual Machine's design or its implementation. 1 Introduction Java [AG96] programs are safe because they can be verified to ensure that they will not damage the computer that they run on, and mobile because they can be compiled for a widely available abstract machine [LY96]. As a result, Java can be used for Internet progr...
E-FRP with priorities
- in EMSOFT ’07: Proceedings of the 7th ACM & IEEE international
"... E-FRP is declarative language for programming resourcebounded, event-driven systems. The original high-level semantics of E-FRP requires that each event handler execute atomically. This requirement facilitates reasoning about E-FRP programs, and therefore it is a desirable feature of the language. B ..."
Abstract
-
Cited by 3 (2 self)
- Add to MetaCart
E-FRP is declarative language for programming resourcebounded, event-driven systems. The original high-level semantics of E-FRP requires that each event handler execute atomically. This requirement facilitates reasoning about E-FRP programs, and therefore it is a desirable feature of the language. But the original compilation strategy requires that each handler complete execution before another event can occur. This implementation choice treats all events equally, in that it forces the upper bound on the time needed to respond to any event to be the same. While this is acceptable for many applications, it is often the case that some events are more urgent than others. In this paper, we show that we can improve the compilation strategy without altering the high-level semantics. With this new compilation strategy, we give the programmer more control over responsiveness without taking away the ability to reason about programs at a high level. The programmer controls responsiveness by declaring priorities for events, and the compilation strategy produces code that uses preemption to enforce these priorities. We show that the compilation strategy enjoys the same properties as the original strategy, with the only change being that the programmer reasons modulo permutations on the order of event arrivals.

