Search

AbstractDelimited continuations are more expressive than traditional abortive continuations and they apparently require a framework beyond traditional continuation-passing style (CPS). We show that this is not the case: standard CPS is sufficient to explain the common control operators for delimited continuations. We demonstrate this fact and present an implementation as a Scheme library. We then investigate a typed account of delimited continuations that makes explicit where control effects can occur. This results in a monadic framework for typed and encapsulated delimited continuations, which we design and implement as a Haskell library. [ABSTRACT FROM AUTHOR]

Haskell's popularity has driven the need for ever more expressive type system features, most of which threaten the decidability and practicality of Damas-Milner type inference. One such feature is the ability to write functions with higher-rank types – that is, functions that take polymorphic functions as their arguments. Complete type inference is known to be undecidable for higher-rank (impredicative) type systems, but in practice programmers are more than willing to add type annotations to guide the type inference engine, and to document their code. However, the choice of just what annotations are required, and what changes are required in the type system and its inference algorithm, has been an ongoing topic of research. We take as our starting point a $\lambda$-calculus proposed by Odersky and Läufer. Their system supports arbitrary-rank polymorphism through the exploitation of type annotations on $\lambda$-bound arguments and arbitrary sub-terms. Though elegant, and more convenient than some other proposals, Odersky and Läufer's system requires many annotations. We show how to use local type inference (invented by Pierce and Turner) to greatly reduce the annotation burden, to the point where higher-rank types become eminently usable. Higher-rank types have a very modest impact on type inference. We substantiate this claim in a very concrete way, by presenting a complete type-inference engine, written in Haskell, for a traditional Damas-Milner type system, and then showing how to extend it for higher-rank types. We write the type-inference engine using a monadic framework: it turns out to be a particularly compelling example of monads in action. The paper is long, but is strongly tutorial in style. Although we use Haskell as our example source language, and our implementation language, much of our work is directly applicable to any ML-like functional language. [ABSTRACT FROM AUTHOR]

Functional dependencies are a popular and useful extension to Haskell style type classes. We give a reformulation of functional dependencies in terms of Constraint Handling Rules (CHRs). In previous work, CHRs have been employed for describing user-programmable type extensions in the context of Haskell style type classes. Here, we make use of CHRs to provide for the first time a concise result that under some sufficient conditions, functional dependencies allow for sound, complete and decidable type inference. The sufficient conditions imposed on functional dependencies can be very limiting. We show how to safely relax these conditions and suggest several sound extensions of functional dependencies. Our results allow for a better understanding of functional dependencies and open up the opportunity for new applications. [ABSTRACT FROM AUTHOR]

Compilers for ML and Haskell typically go to a good deal of trouble to arrange that multiple arguments can be passed efficiently to a procedure. For some reason, less effort seems to be invested in ensuring that multiple results can also be returned efficiently. In the context of the lazy functional language Haskell, we describe an analysis, Constructed Product Result (CPR) analysis, that determines when a function can profitably return multiple results in registers. The analysis is based only on a function's definition, and not on its uses (so separate compilation is easily supported) and the results of the analysis can be expressed by a transformation of the function definition alone. We discuss a variety of design issues that were addressed in our implementation, and give measurements of the effectiveness of our approach across a substantial benchmark set. Overall, the price/performance ratio is good: the benefits are modest in general (though occasionally dramatic), but the costs in both complexity and compile time, are low. [ABSTRACT FROM AUTHOR]

27.1 The RandomGen class, and the StdGen generator 236 27.2 The Random class 239 27.3 The global random number generator 240 [ABSTRACT FROM AUTHOR]

20.1 Naming Conventions 200 20.2 Class MonadPlus 200 20.3 Functions 201 20.4 Library Monad 202 [ABSTRACT FROM AUTHOR]

24.1 Library Time 227 [ABSTRACT FROM AUTHOR]

Directory Functions 219 [ABSTRACT FROM AUTHOR]

21.1 I/O Errors 207 21.2 Files and Handles 208 21.3 Opening and Closing Files 210 21.4 Determining the Size of a File 211 21.5 Detecting the End of Input 211 21.6 Buffering Operations 211 21.7 Repositioning Handles 213 21.8 Handle Properties 213 21.9 Text Input and Output 214 21.10 Examples 215 21.11 Library IO 216 [ABSTRACT FROM AUTHOR]

19.1 Library Char 195 [ABSTRACT FROM AUTHOR]

12.1 Library Ratio 150 [ABSTRACT FROM AUTHOR]

16.1 Array Construction 174 16.2 Incremental Array Updates 175 16.3 Derived Arrays 176 16.4 Library Array 176 [ABSTRACT FROM AUTHOR]

15.1 Deriving Instances of Ix 170 15.2 Library Ix 171 [ABSTRACT FROM AUTHOR]

14.1 Showing Functions 158 14.2 Reading Functions 159 14.3 Miscellaneous 159 14.4 Library Numeric 160 [ABSTRACT FROM AUTHOR]

13.1 Library Complex 154 [ABSTRACT FROM AUTHOR]

17.1 Indexing Lists 181 17.2 “Set” Operations 181 17.3 List Transformations 182 17.4 unfoldr 182 17.5 Predicates 183 17.6 The “By” Operations 183 17.7 The “generic” Operations 184 17.8 Further “zip” Operations 184 17.9 Library List 184 [ABSTRACT FROM AUTHOR]

10.1 Derived Instances of Eq and Ord 140 10.2 Derived Instances of Enum 140 10.3 Derived Instances of Bounded 141 10.4 Derived Instances of Read and Show 142 10.5 An Example 143 [ABSTRACT FROM AUTHOR]

9.1 Notational Conventions 125 9.2 Lexical Syntax 126 9.3 Layout 128 9.4 Literate Comments 131 9.5 Context-Free Syntax 133 [ABSTRACT FROM AUTHOR]

8.1 Module Prelude 104 8.2 Module PreludeList 114 8.3 Module PreludeText 119 8.4 Module PreludeIO 123 [ABSTRACT FROM AUTHOR]

7.1 Standard I/O Functions 97 7.2 Sequencing I/O Operations 99 7.3 Exception Handling in the I/O Monad 100 [ABSTRACT FROM AUTHOR]

6.1 Standard Haskell Types 81 6.2 Strict Evaluation 84 6.3 Standard Haskell Classes 84 6.4 Numbers 91 [ABSTRACT FROM AUTHOR]

2.1 Notational Conventions 7 2.2 Lexical Program Structure 8 2.3 Comments 9 2.4 Identifiers and Operators 10 2.5 Numerical Literals 11 2.6 Character and String Literals 12 2.7 Layout 13 [ABSTRACT FROM AUTHOR]

4.1 Overview of Types and Classes 40 4.2 User-Defined datatypes 45 4.3 Type Classes and Overloading 49 4.4 Nested Declarations 55 4.5 Static Semantics of Function and Pattern Bindings 60 4.6 Kind Inference 66 [ABSTRACT FROM AUTHOR]

CPU Time 233 [ABSTRACT FROM AUTHOR]

System Functions 223 [ABSTRACT FROM AUTHOR]

18.1 Library Maybe 192 [ABSTRACT FROM AUTHOR]

11.1 Inlining 145 11.2 Specialization 145 [ABSTRACT FROM AUTHOR]