Abstract not found

Some modern superscalar microprocessors provide only imprecise exceptions. That is, they do not guarantee to report the same exception that would be encountered by a straightforward sequential execution of the program. In exchange, they offer increased performance or decreased chip area (which amount to much the same thing). This performance/precision tradeoff has not so far been much explored at the programming language level. In this paper we propose a design for imprecise exceptions in the lazy functional programming language Haskell. We discuss several designs, and conclude that imprecision is essential if the language is still to enjoy its current rich algebra of transformations. We sketch a precise semantics for the language extended with exceptions. The paper shows how to extend Haskell with exceptions without crippling the language or its compilers. We do not yet have enough experience of using the new mechanism to know whether it strikes an appropriate balance between expressiveness and pwrformance.

We introduce the design of Mondrian, a functional scripting language for glueing together components on the .NET platform.

The Glasgow Haskell Compiler (GHC) has quite sophisticated support for concurrency in its runtime system, which is written in lowlevel C code. As GHC evolves, the runtime system becomes increasingly complex, error-prone, difficult to maintain and difficult to add new concurrency features. This paper presents an alternative approach to implement concurrency in GHC. Rather than hard-wiring all kinds of concurrency features, the runtime system is a thin substrate providing only a small set of concurrency primitives, and the remaining concurrency features are implemented in software libraries written in Haskell. This design improves the safety of concurrency support; it also provides more customizability of concurrency features, which can be developed as Haskell library packages and deployed modularly. Categories and Subject Descriptors D.1.1 [Programming Techniques]:

Categories and Subject Descriptors D.3.2 [Language Classifica-tions]: Applicative (functional) languages General Terms Languages, Performance 1. Introduction For many years the easiest approach to getting software to gofaster has been to sit around and save up for a new machine (and then preferably run the old software on it). It is becoming clear,however, that this free lunch is over [22]. Processor manufacturers have stopped struggling to push clock speeds much further, and areturning their attention to parallelism instead. Multi-core processors, with several symmetric processing cores on a single chip, will bethe norm in consumer machines within the next 1-2 years. The software challenge is to take advantage of this extra processingpower through parallelism.

Using a language without exception handling is like driving a car with no brakes and no seatbelt --- things work fine until something goes wrong. You also learn to drive rather carefully. This paper describes an exception handling extension to the Haskell lazy functional language. The implementation turned out to be very easy but we had problems finding a viable semantics for our system. The resulting semantics is a compromise between theoretical beauty and practical utility. 1 Introduction Haskell is an ivory tower language: full of lofty ideas, built on solid semantic foundations, praised by grey-bearded professors and about as much use in the real world as a chocolate teapot. For Haskell to emerge from the ivory tower, it must be possible to write the kinds of programs that less idealistic programmers can write in C, Java, Ada and other useful languages: programs that interact with the real world in interesting ways (using graphics, GUIs, databases, etc) and which are robust enough...

First, I thank my dissertation advisor, Steve Zdancewic, who has always been supportive to me in the last five years. Steve taught me how to do research, co-authored many papers with me, gave me insightful feedbacks and practically line-by-line writing advices, encouraged me to look for research directions that I am most interested in and obtained funding for my dissertation research. As an advisor, he could not have been more helpful. My other mentors on programming languages research also deserve my thanks. Benjamin Pierce enlightened me on functional programming and the theory of programming languages; Stephanie Weirich impressed me on what type systems can do; Simon Peyton Jones educated me on the principles and philosophies of language design; Simon Marlow showed me how far one can go to make things run faster. In particular, I thank Benjamin Pierce and Stephanie Weirich for serving in my thesis committee. I thank all the PL Club members for sharing their knowledge in the weekly discussions. I particularly thank Geoffery Washburn for helping me out with the CIS-670 project and patiently explaining programming language concepts to me when I first started doing research in programming languages. I should also give special thanks to Stephen Tse who has been a great friend to talk about information-flow type systems and functional programming.