Every programming language needs a debugger. Mercury now has three debuggers: a simple procedural debugger similar to the tracing systems of Prolog implementations, a prototype declarative debugger, and a debugger based on the idea of automatic trace analysis. In this paper, we present the shared infrastructure that underlies the three debuggers, and describe the implementation of the procedural debugger. We give our reasons for each of our main design decisions, and show how several of these decisions are rooted in our experience with the debugging of large programs working with large data structures.

Previous attempts at garbage collection in uncooperative environments have generally used conservative or mostly conservative approaches. We describe a technique for doing fully type-accurate garbage collection in an uncooperative environment, using a "shadow stack" to link structs of pointer-containing variables, together with the data or code needed to trace them. We have implemented this in the Mercury compiler, which generates C code, and present preliminary performance data on the overheads of this technique. We also show how this technique can be extended to handle multithreaded applications.

. In this paper we present a binding-time analysis for the logic programming language Mercury. Binding-time analysis is a key analysis needed to perform o-line program specialisation. Our analysis deals with the higher-order aspects of Mercury, and is formulated by means of constraint normalisation. This allows (at least part of) the analysis to be performed on a modular basis. 1 Introduction Mercury is a recently introduced logic programming language, comprising many features needed for modern software engineering practice: polymorphism, typeclasses and a strong module system are some examples of the means available to the programmer to design and build modular programs that employ a lot of abstraction and reuse of general components. Employing abstraction and generality, however, imposes a penalty on the e- ciency of the resulting program due to the presence of for example procedure calls and tests for which the input is (partially) known at compile-time. To overcome this pe...

The .NET Common Language Runtime (CLR) o ers a new opportunity to experiment with multi-language interoperation, and provides a relatively rare chance to explore deep interoperation of a wide range of programming language paradigms. This article describes how the logic/functional programming language Mercury is compiled to the CLR. We describe the problems we have encountered with generating code for the CLR, give some preliminary benchmark results, and suggest some possible improvements to the CLR regarding separate compilation, verifiability, tail calls, and efficiency.

Compile-time garbage collection (CTGC) is still a very uncommon feature within compilers. In previous work we have developed a compile-time structure reuse system for Mercury, a logic programming language. This system indicates which datastructures can safely be reused at run-time. As preliminary experiments were promising, we have continued this work and have now a working and well performing near-toship CTGC-system built into the Melbourne Mercury Compiler (MMC).

Despite these expected benefits, declarative debugging is not yet widely used in practice to find real bugs. There are three main reasons for this: 1. Most previous declarative debuggers only support a subset of the features of their target language that is not sufficient to express real programs. 2. Previous declarative debuggers do not scale well when applied to problems with large search spaces. 3. Previous declarative debuggers do not do enough to make the questions easier for the user to answer. The declarative nature of Mercury makes it relatively easy to implement a declarative debugger that can handle the full language. The version of the Mercury declarative debugger that was the starting point for this thesis already handled almost all of Mercury. By extending it to handle exceptions we made it handle the full language

This paper describes the design and construction of a Haskell source-level debugger built into the GHCi interactive environment. We have taken a pragmatic approach: the debugger is based on the traditional stop-examine-continue model of online debugging, which is simple and intuitive, but has traditionally been shunned in the context of Haskell because it exposes the lazy evaluation order. We argue that this drawback is not as severe as it may seem, and in some cases is an advantage. The design focusses on availability: our debugger is intended to work on all programs that can be compiled with GHC, and without requiring the programmer to jump through additional hoops to debug their program. The debugger has a novel approach for reconstructing the type of runtime values in a polymorphic context. Our implementation is light on complexity, and was integrated into GHC without significant upheaval. 1.

The aim of this thesis is the design of a type system for an industrial strength logic programming language. The type system we describe has been implemented for the Mercury programming language, in the Melbourne Mercury compiler.

Compile-time garbage collection is still a very uncommon feature within compilers. In previous work we have developed a compiletime structure reuse system for Mercury, a logic programming language. This system derives so called reuse information. This information indicates which datastructures can safely be reused at run-time. As preliminary experiments were promising, we have continued this work and have now a working and well performing near-toship compile-time garbage collection system built into the Melbourne Mercury Compiler. In this paper we present the multiple design decisions leading to this system, we report the results of using compile time garbage collection for a set of benchmarks, including real-world programs, and nally we discuss further possible improvements. Benchmarks show substantial memory savings and a noticeable reduction in execution time. Keywords : Program Analysis, Mercury, Compile-time Garbage Collection CR Subject Classication : D.3.4, I.2.3 Practical Aspects for a working Compile Time Garbage Collection System for Mercury Nancy Mazur, Peter Ross ? , Gerda Janssens, and Maurice Bruynooghe Department of Computer Science, K.U.Leuven Celestijnenlaan, 200A, B{3001 Heverlee, Belgium fnancy,gerda,mauriceg@cs.kuleuven.ac.be petdr@miscrit.be Abstract. Compile-time garbage collection is still a very uncommon feature within compilers. In previous work we have developed a compiletime structure reuse system for Mercury, a logic programming language. This system derives so called reuse information. This information indicates which datastructures can safely be reused at run-time. As preliminary experiments were promising, we have continued this work and have now a working and well performing near-to-ship compile-time ga...

For any LP system, tabling can be quite handy in a variety of tasks, especially if it is efficiently implemented and fully integrated in the language. Implementing tabling in Mercury poses special challenges for several reasons. First, Mercury is both semantically and culturally quite different from Prolog. While decreeing that tabled predicates must not include cuts is acceptable in a Prolog system, it is not acceptable in Mercury, since if-then-elses and existential quantification have sound semantics for stratified programs and are used very frequently both by programmers and by the compiler. The Mercury implementation thus has no option but to handle interactions of tabling with Mercury’s language features safely. Second, the Mercury implementation is vastly different from the WAM, and many of the differences (e.g. the absence of a trail) have significant impact on the implementation of tabling. In this paper, we describe how we adapted the copying approach to tabling to implement minimal model tabling in Mercury.