. The paper presents several analyses to detect non-deterministic expressions in the parallel-functional language Eden. First, the need for the analysis is motivated, and then each one is presented. The first one is type-based, while the other two are based on abstract interpretation. Their power and efficiency is discussed, and an example is used to illustrate the differences. Two interesting functions to adapt abstract values to types appear, and they happen to be a Galois connection. 1 Introduction The paper presents several analyses to determine when an Eden [BLOMP96] expression is sure to be deterministic, and when it may be non-deterministic. The parallel-functional language Eden extends the lazy functional language Haskell by constructs to explicitly define and communicate processes. The three main new concepts are process abstractions, process instantiations and the nondeterministic process abstraction merge. Process abstractions of type Process a b can be compared to ...

Non-determinism may affect the referential transparency of the programs written in Eden: If a nondeterministic expression is evaluated in different processes, the variable it is bound to it will denote possibly different values. It would be desirable to warn the programmer about this situation, or to force the evaluation of such an expression so that all the occurrences of the variable have the same value. Additionally there exist sequential transformations that are incorrect when non-determinism is involved. Such transformations should be applied only to those parts of the program that are sure to be deterministic. In this paper several analyses of different efficiency and power are presented. Several techniques are used: A types annotation system and abstract interpretation. 1 Introduction The parallel-functional language Eden extends the lazy functional language Haskell by syntactic constructs to explicitly define and communicate processes. The three main new concepts are process a...

It is common for compilers to derive the calling convention of a function from its type. Doing so is simple and modular but misses many optimisation opportunities, particularly in lazy, higher-order functional languages with extensive use of currying. We restore the lost opportunities by defining Strict Core, a new intermediate language whose type system makes the missing distinctions: laziness is explicit, and functions take multiple arguments and return multiple results.

In this paper we demonstrate how to relate the semantics given by the nondeterministic call-by-need calculus FUNDIO [SS03] to Haskell. After introducing new correct program transformations for FUNDIO, we translate the core language used in the Glasgow Haskell Compiler into the FUNDIO language, where the IO construct of FUNDIO corresponds to direct-call IO-actions in Haskell. We sketch the investigations of [Sab03b] where a lot of program transformations performed by the compiler have been shown to be correct w.r.t. the FUNDIO semantics. This enabled us to achieve a FUNDIO-compatible Haskell-compiler, by turning off not yet investigated transformations and the small set of incompatible transformations. With this compiler, Haskell programs which use the extension unsafePerformIO

It is common for compilers to derive the calling convention of a function from its type. Doing so is simple and modular but misses many optimisation opportunities, particularly in lazy, higher-order functional languages with extensive use of currying. We restore the lost opportunities by defining Strict Core, a new intermediate language whose type system makes the missing distinctions: laziness is explicit, and functions take multiple arguments and return multiple results. Categories and Subject Descriptors D.3.1 [Programming Languages]:

Recent trends in programming language implementation are moving more and more towards “managed ” runtime environments. These offer many benefits, including static and dynamic type checking, security, profiling, bounds checking and garbage collection. The Common Language Infrastructure (CLI) is Microsoft’s attempt to define a managed runtime environment. However, since it was designed with more mainstream languages in mind, including C ♯ and C++, CLI proves restrictive when compiling functional languages. More specifically, for compilers such as GHC, which compiles Haskell, the CLI provides little support for lazy evaluation, currying (partial applications) and static type checking. The CLI does not provide any way of representing a computation in an evaluated and non-evaluated form. It does not allow functions to directly manipulate the runtime stack, and it restricts static typing in various forms; including subsumption over function types. In this thesis, we describe a new compilation method that removes the need for runtime argument checks. Runtime argument checking is required to