ESPRIT Project 25503: ARGo (Summary)

Objectives of the project

The ARGO project has several objectives all related to providing an industrial strength Logic Programming environment based on the new language Mercury[8,7].

Mercury has many attractive features over Prolog when seen from an industrial perspective. Indeed, the language mandates that programmers provide information which are useful for both the compiler (to optimise the generated code) and programmer teams as these annotations provide documentation on intended usage of predicates and functions defined in programs. The important information describing types and modes as well as a powerful module system allow teams to cooperate and define proper interfaces that ease collaboration and teamwork. This information also provides documentation that is consistent with the code (since the compiler verifies it).

The objectives of ARGo can thus be stated as follows:

• Provide an industrial grade and well integrated version of Mercury for the Windows NT platform, based on a Melbourne initial release.
• Develop a methodology for development in Mercury, based on Yves Deville's seminal book [2].
• Enhance the current set of tools usable by the compiler to further improve the quality of the language and system.
• Demonstrate the relevance of the approach by rewriting and evaluating 2 existing applications.

Project organisation

The consortium has the following structure :

Abbrev	Denomination	Country	Role
MC	Mission Critical	BE	Coordinator
KUL	Katholieke Universiteit Leuven, dept. of Computer Science	BE	Partner
DEX	Thomson-CSF Detexis	FR	Partner
FUNDP	Faculté Universitaire Notre Dame de la Paix	BE	Partner
INRIA	Institut National de Recherche en Informatique et Automatique	FR	Partner
MU	Melbourne University	AU	Non EU Partner

Achievements

The project has achieved the following aspects:

Mercury-ARGo:

A version of the Melbourne compiler has been adapted to run on Windows NT and take advantage of the Microsoft Visual C compiler. The applications developed with Mercury-ARGo do require the Cygnus Cygwin library and use the Microsoft C runtime. The system has been extended to integrate Microsoft COM components into Mercury applications. The system has been demonstrated with a database access component ADO (Active Data Objects) and with the Microsoft Agent component.

Applications:

DEX has rewritten in Mercury an application for model based diagnosis and compared the effort and rewritten system with the previous versions (Prolog and C++). MC has rewritten components of a tarification application for hospitals. Those efforts showed that usage of Mercury is indeed very helpful but that the current implementation still has some rough edges (memory consumption, some missing features, performance in some cases,...)

Methodology:

The programming methodology of logic program construction developed for Prolog in [2] has been adapted [1] for Mercury by FUNDP and MC. Medium-size programs have been developed according to the methodology. In particular, FUNDP has developed, within the methodology, a generic parser of EBNF grammars. This parser solves a previously unsolved problem for Mercury: dealing with files that are so large that the complete list of tokens cannot be built before parsing starts. The schema of specifications provided by the methodology allows us to derive the final (complicated and hard to understand without understanding the transformation process) version of the parser from a first and ``obviously'' correct version by a series of systematic transformation steps. The specification schema was also proven to be useful for other kinds of methodologies used by other partners such as ``reuse'' (MC) and ``reverse engineering'' (DEX). Finally, parts of the rewritten applications have been reconstructed according to the methodology.

Advanced topics:

• The details of a liveness analysis for Mercury have been worked out and implemented. The foundations for a module based analysis have been developed. A prototype, annotating Mercury programs with opportunities for memory reuse has been developed. The prototype includes support for modules [6].

• Theoretical foundations for binding-time analysis with respect to Mercury have been developed. A prototype of a binding-time analyser, the core component of an off-line specialiser, has been completed. Implementation of an elementary specialiser has been initiated [9].
• The automated debugger OPIUM-M has been released and its documentation has been completed. OPIUM-M is an extensible debugging environment for Mercury which offers support for high-level debugging strategies. Opium-M allows execution trace analyses to be automated. The IRISA team has written some extensions which show that a tracer with a trace analyser can be used to achieve more than debugging. In particular, the team has computed coverage ratios for test cases and execution monitors. Thus, instead of building ad hoc instrumentations, one can use a uniform environment which allows a synergy between the tools to take place [5,4,3].

Perspectives

The important conclusions and perspectives from this projects are:

• The Mercury system has been used for real applications by industrial teams and the experience was globally successful. The evaluation of the language and system showed that some aspects of the language are difficult to use (IO, modes other than in/out,...) but that quality of the applications improves thanks to the language and compiler.
• A second source implementation of Mercury, with industrial goals only, is mandatory to separate industrial objectives from research objectives and to include aspects which are critical for industrial acceptance. Among those aspects, liveness analysis and destructive updates, a native garbage collector, full support for components (exploitation and delivery), and native code generation are the most important.
• Deville's methodology (originally for Prolog) is easier to apply with Mercury but other methodological approaches can be readily combined and used with Mercury. In particular, Mercury often leads one to use a functional approach.
• Liveness analysis of Mercury programs is feasible and uncovers many potential places for memory reuse in real code. Those optimisations should be integrated into the Mercury system.

Contacts

Bibliography

1

D. Baldan, B. Le Charlier, C. Leclère, and I. Pollet.
A Step Towards a Methodology for Mercury Program Construction: A Declarative Semantics for Mercury.
In Post-Proceedings of (LOPSTR'98), number 1559 in Lecture Notes in Computer Science. Springer Verlag, 1999.

2

Yves Deville.
Logic Programming. Systematic Program Development.
Addison-Wesley, 1990.

3

M. Ducassé and E. Jahier.
An automated debugger for Mercury - Opium-M 0.1 User and reference manuals.
Technical report 231, INRIA, May 1999.
Also IRISA PI 1234.

4

E. Jahier and M. Ducassé.
A generic approach to monitor program executions.
In D. De Schreye, editor, Proceedings of the International Conference on Logic Programming. MIT Press, November 1999.

5

E. Jahier and M. Ducassé.
Un traceur d'exécution ne sert pas qu'au débogage.
In F. Fages, editor, Actes des journées francophones de programmation logique et programmation par contraintes, pages 297-311. Hermes, June 1999.

6

N. Mazur, G. Janssens, and M. Bruynooghe.
Towards memory reuse for Mercury.
Technical report, KU-Leuven, 1999.
Accepted for Int. Workshop on Implementation of Declarative Languages, Oct. 99, Paris.

7

Melbourne University.
Mercury Language Reference Manual, 1998.
http://www.cs.mu.oz.au/research/mercury/information/documentation.html.

8

Zoltan Somogyi, Fergus Henderson, and Thomas Conway.
The execution algorithm of Mercury, an efficient purely declarative logic programming language.
Journal of Logic Programming, 29(1-3):17-64, October-November 1996.

9

W. Vanhoof and M. Bruynooghe.
Binding-time analysis for Mercury,.
In D. De Schreye, editor, Proceedings of the International Conference on Logic Programming. MIT Press, November 1999.