-
M. Ducassé.
Abstract views of Prolog executions with Opium.
In P. Brna,
B. du Boulay,
and H. Pain, editors, Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study,
Cognitive Science and Technology.
Ablex,
1999.
[WWW]
Keyword(s): Software engineering,
Programming environment,
Automated debugging,
Trace abstraction mechanisms,
Debugging language,
Program behavior understanding,
Prolog Debugging tool.
Abstract: |
Opium is a system for analysing and debugging Prolog programs. Its kernel comprises an execution tracer and a programming language with a set of primitives for trace and source analysis. In this chapter we show the power of Opium for supporting abstract views of Prolog executions. Abstract views give high-level points of view about executions. They filter out irrelevant details; they restructure the remaining information; and they compact it so that the amount of information given at each step has a reasonable size. The examples of abstract views given in the following are a goal execution profile, some data abstractions, an instantiation profile, a failure analysis, a loop analysis, and a kind of explanation for an expert system written in Prolog. |
@InCollection{ducasse99b,
Author = {M. Ducassé},
url = {http://www.irisa.fr/lande/ducasse/ducasse-ablex99.ps.gz},
Title = {Abstract views of {Prolog} executions with {Opium}},
BookTitle = {Learning to Build and Comprehend Complex Information Structures: Prolog as a Case Study},
Publisher = {Ablex},
Series = {Cognitive Science and Technology},
Year = {1999},
Editor = {P. Brna and B. du Boulay and H. Pain},
keywords = {Software engineering, Programming environment, Automated debugging, Trace abstraction mechanisms , Debugging language, Program behavior understanding, Prolog Debugging tool},
abstract = {Opium is a system for analysing and debugging Prolog programs. Its kernel comprises an execution tracer and a programming language with a set of primitives for trace and source analysis. In this chapter we show the power of Opium for supporting abstract views of Prolog executions. Abstract views give high-level points of view about executions. They filter out irrelevant details; they restructure the remaining information; and they compact it so that the amount of information given at each step has a reasonable size. The examples of abstract views given in the following are a goal execution profile, some data abstractions, an instantiation profile, a failure analysis, a loop analysis, and a kind of explanation for an expert system written in Prolog. }
}
-
C. Belleannée,
P. Brisset,
and Olivier Ridoux.
A Pragmatic Reconstruction of $\lambda$Prolog.
J. Logic Programming,
41(1):67-102,
1999.
@Article{BEL99,
author = {C. Belleannée and P. Brisset and Olivier Ridoux},
title = "A Pragmatic Reconstruction of $\lambda${Prolog}",
journal = "J. Logic Programming",
year = 1999,
volume = 41,
number = 1,
pages = "67--102"
}
-
M. Ducassé.
Opium: An extendable trace analyser for Prolog.
The Journal of Logic programming,
1999.
Note: Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds), Also Rapport de recherche INRIA RR-3257 and Publication Interne IRISA PI-1127.
[WWW]
Keyword(s): Software Engineering,
Automated Debugging,
Trace Query Language,
Program Execution Analysis,
Abstract Views of Program Executions,
Prolog.
Abstract: |
Traces of program executions are a helpful source of information for program debugging. They, however, give a picture of program executions at such a low level that users often have difficulties to interpret the information. Opium, our extendable trace analyzer, is connected to a ``standard'' Prolog tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions. Users can therefore examine program executions at the levels of abstraction which suit them. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes in depth the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specified and implemented within a few days. They show how to use Opium for real applications. |
@Article{ducasse99,
Author = {M. Ducassé},
url = {http://www.irisa.fr/lande/ducasse/ducasse-jlp-98.ps.gz},
Title = {Opium: An extendable trace analyser for {Prolog}},
Journal = {The Journal of Logic programming},
Year = {1999},
Note = {Special issue on Synthesis, Transformation and Analysis of Logic Programs, A. Bossi and Y. Deville (eds), Also Rapport de recherche INRIA RR-3257 and Publication Interne IRISA PI-1127},
keywords = {Software Engineering, Automated Debugging, Trace Query Language, Program Execution Analysis, Abstract Views of Program Executions, Prolog},
abstract = {Traces of program executions are a helpful source of information for program debugging. They, however, give a picture of program executions at such a low level that users often have difficulties to interpret the information. Opium, our extendable trace analyzer, is connected to a ``standard'' Prolog tracer. Opium is programmable and extendable. It provides a trace query language and abstract views of executions. Users can therefore examine program executions at the levels of abstraction which suit them. Opium has shown its capabilities to build abstract tracers and automated debugging facilities. This article describes in depth the trace query mechanism, from the model to its implementation. Characteristic examples are detailed. Extensions written so far on top of the trace query mechanism are listed. Two recent extensions are presented: the abstract tracers for the LO (Linear Objects) and the CHR (Constraint Handling Rules) languages. These two extensions were specified and implemented within a few days. They show how to use Opium for real applications. }
}
-
M. Ducassé.
An introduction to the B formal method.
In A.-L. Bossi, editor,
Proceedings of the 9th International Workshop on LOgic-based Program Synthesis and TRansformation,
pages 23-30,
September 1999.
Universita' Ca' Foscari di Venezia.
Note: Technical report CS-99-16, Slides.
@InProceedings{ducasse99d,
Author={M. Ducassé},
Title={An introduction to the B formal method},
Pages={23--30},
BookTitle={Proceedings of the 9th International Workshop on LOgic-based Program Synthesis and TRansformation},
Year={1999},
Editor={A.-L. Bossi},
Publisher={Universita' Ca' Foscari di Venezia},
Month={September},
Note={Technical report CS-99-16, Slides}
}
-
M. Ducassé.
Coca: An automated Debugger for C.
In Proceedings of the 21st International Conference on Software Engineering,
pages 504-513,
May 1999.
ACM Press.
[WWW]
Keyword(s): Software engineering,
Programming environment,
Automated debugging,
Trace query mechanism,
Debugging language,
Program behavior understanding,
C Debugging tool..
Abstract: |
We present Coca, an automated debugger for C, where the breakpoint mechanism is based on events related to language constructs. Events have semantics whereas source lines used by most debuggers do not have any. A trace is a sequence of events. It can be seen as an ordered relation in a database. Users can specify precisely which events they want to see by specifying values for event attributes. At each event, visible variables can be queried. The trace query language is Prolog with a handful of primitives. The trace query mechanism searches through the execution traces using both control flow and data whereas debuggers usually search according to either control flow or data. As opposed to fully ``relational'' debuggers which use plain database querying mechanisms, Coca trace querying mechanism does not require any storage. The analysis is done on the fly, synchronously with the traced execution. Coca is therefore more powerful than ``source line'' debuggers and more efficient than relational debuggers. |
@InProceedings{ducasse99c,
Author={M. Ducassé},
Title={Coca: An automated Debugger for {C}},
Pages={504-513},
BookTitle={Proceedings of the 21st International Conference on Software Engineering},
Year={1999},
Publisher={ACM Press},
Month={May},
Annote={Also RR-3489},
url = {http://www.irisa.fr/lande/ducasse/coca-irisa-98.ps.gz},
keywords = {Software engineering, Programming environment, Automated debugging, Trace query mechanism, Debugging language, Program behavior understanding, C Debugging tool. },
abstract = {We present Coca, an automated debugger for C, where the breakpoint mechanism is based on events related to language constructs. Events have semantics whereas source lines used by most debuggers do not have any. A trace is a sequence of events. It can be seen as an ordered relation in a database. Users can specify precisely which events they want to see by specifying values for event attributes. At each event, visible variables can be queried. The trace query language is Prolog with a handful of primitives. The trace query mechanism searches through the execution traces using both control flow and data whereas debuggers usually search according to either control flow or data. As opposed to fully ``relational'' debuggers which use plain database querying mechanisms, Coca trace querying mechanism does not require any storage. The analysis is done on the fly, synchronously with the traced execution. Coca is therefore more powerful than ``source line'' debuggers and more efficient than relational debuggers. }
}
-
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,
November 1999.
MIT Press.
[WWW]
Keyword(s): Monitoring,
Trace analysis,
Flexibility,
Logic programming,
Mercury.
Abstract: |
Monitoring requires to gather data about executions. The monitoring functionalities currently available are built on top of ad hoc instrumentations. Most of them are implemented at low-level; in any case they require an in-depth knowledge of the system to instrument. The best people to implement these instrumentations are generally the implementors of the compiler. They, however, cannot decide which data to gather. Indeed, hundreds of variants can be useful and only end-users know what they want.
In this article, we propose a primitive which enables users to easily specify what to monitor. It is built on top of the tracer of the Mercury compiler. We illustrate how to use this primitive on two different kinds of monitoring. Firstly, we implement monitors that collect various kinds of statistics; each of them is well-known, the novelty is that users can get exactly the variants they need. Secondly, we define two notions of test coverage for logic programs and show how to measure coverage rates with our primitive. To our knowledge no definition of test coverage exist for logic programming so far. Each example is only a few lines of Mercury. Measurements show that the performance of the primitive on the above examples is acceptable for an execution of several millions of trace events. Our primitive, although simple, lays the foundation for a generic and powerful monitoring environment. |
@InProceedings{jahier99d,
Author={E. Jahier and M. Ducassé},
Title={A generic approach to monitor program executions},
Pages={},
BookTitle={Proceedings of the International Conference on Logic Programming},
Year={1999},
Editor={D. De Schreye},
Publisher={MIT Press},
Month={November},
Location={mireille: whole proceedings},
url = {ftp://ftp.irisa.fr/local/lande/ej-md-iclp99.ps.gz},
keywords = {Monitoring, Trace analysis, Flexibility, Logic programming, Mercury},
abstract = { Monitoring requires to gather data about executions. The monitoring functionalities currently available are built on top of ad hoc instrumentations. Most of them are implemented at low-level; in any case they require an in-depth knowledge of the system to instrument. The best people to implement these instrumentations are generally the implementors of the compiler. They, however, cannot decide which data to gather. Indeed, hundreds of variants can be useful and only end-users know what they want.
In this article, we propose a primitive which enables users to easily specify what to monitor. It is built on top of the tracer of the Mercury compiler. We illustrate how to use this primitive on two different kinds of monitoring. Firstly, we implement monitors that collect various kinds of statistics; each of them is well-known, the novelty is that users can get exactly the variants they need. Secondly, we define two notions of test coverage for logic programs and show how to measure coverage rates with our primitive. To our knowledge no definition of test coverage exist for logic programming so far. Each example is only a few lines of Mercury. Measurements show that the performance of the primitive on the above examples is acceptable for an execution of several millions of trace events. Our primitive, although simple, lays the foundation for a generic and powerful monitoring environment. }
}
-
E. Jahier and M. Ducassé.
Un traceur d'exécutions de programmes ne sert pas qu'au débogage.
In F. Fages, editor,
Actes des Journées francophones de Programmation Logique et par Contraintes,
Lyon,
juin 1999.
Hermès.
[WWW]
Keyword(s): Dynamic analysis,
Trace analysis,
Monitoring,
Measure of test coverage,
Logic programming,
Mercury.
Abstract: |
In this paper we show that a tracer with a trace analyser can be used to achieve more than debugging. We first illustrate how to compute coverage ratios for test cases. We also give 4 examples to monitor the behavior of programs. Thus, instead of building ad hoc instrumentations, which is currently the case for such tools, one can use a uniform environment which allows a synergy between the tools to take place. As a matter of fact, while studying the test coverage measurement we enriched the trace information, to the benefit of the other tools. Moreover, ad hoc instrumentations require an in depth knowledge of the system to instrument, either at low level or by source to source transformation. Even it is not technically difficult, it always requires a significant programming effort. On the opposite, with our approach, the instrumentation is generic. It is done once for all, and the specific analyses can be relatively simple. The examples of this article consist of less than a dozen of Prolog lines each. |
@InProceedings{jahier99b,
author = {E. Jahier and M. Ducassé},
title = {Un traceur d'exécutions de programmes ne sert pas qu'au débogage},
booktitle = {Actes des Journées francophones de Programmation Logique et par Contraintes},
editor = {F. Fages},
year = 1999,
month = {juin},
publisher = {Hermès},
address = {Lyon},
url = {ftp://ftp.irisa.fr/local/lande/ej-md-jfplc99.ps.gz},
keywords = {Dynamic analysis, Trace analysis, Monitoring, Measure of test coverage, Logic programming, Mercury},
abstract = {In this paper we show that a tracer with a trace analyser can be used to achieve more than debugging. We first illustrate how to compute coverage ratios for test cases. We also give 4 examples to monitor the behavior of programs. Thus, instead of building ad hoc instrumentations, which is currently the case for such tools, one can use a uniform environment which allows a synergy between the tools to take place. As a matter of fact, while studying the test coverage measurement we enriched the trace information, to the benefit of the other tools. Moreover, ad hoc instrumentations require an in depth knowledge of the system to instrument, either at low level or by source to source transformation. Even it is not technically difficult, it always requires a significant programming effort. On the opposite, with our approach, the instrumentation is generic. It is done once for all, and the specific analyses can be relatively simple. The examples of this article consist of less than a dozen of Prolog lines each.}
}
-
E. Jahier,
M. Ducassé,
and O. Ridoux.
Specifying trace models with a continuation semantics.
In M. Ducassé,
A. Kusalik,
L. Naish,
and G. Puebla, editors,
Proc. of ICLP'99 Workshop on Logic Programming Environments,
1999.
Note: LPE'99.
[WWW]
Keyword(s): trace models,
continuation semantics,
specification,
validation,
Logic programming.
Abstract: |
In this article, we have give a formal specification of Byrd's box model and we show how this specification can be extended to specify richer trace models. We have also sho how these specifications can be executed by a direct translation into lambda-Prolog, leading to a Prolog interpreter that performs execution traces. This interpreter can be used both to experiment various trace models and to validate the different event specifications. Hence we have a formal framework to specify and prototype trace models. |
@InProceedings{jahier99e,
author={E. Jahier and M. Ducassé and O. Ridoux},
title={Specifying trace models with a continuation semantics},
booktitle={Proc. of ICLP'99 Workshop on Logic Programming Environments},
editor={M. Ducassé and A. Kusalik and L. Naish and G. Puebla},
year={1999},
note = {LPE'99},
url={ftp://ftp.irisa.fr/local/lande/ej-md-or-lpe99.ps.gz},
keywords = {trace models, continuation semantics, specification, validation, Logic programming},
abstract = {In this article, we have give a formal specification of Byrd's box model and we show how this specification can be extended to specify richer trace models. We have also sho how these specifications can be executed by a direct translation into lambda-Prolog, leading to a Prolog interpreter that performs execution traces. This interpreter can be used both to experiment various trace models and to validate the different event specifications. Hence we have a formal framework to specify and prototype trace models.}
}
-
S. Mallet and M. Ducassé.
Generating deductive database explanations.
In D. De Schreye, editor,
Proceedings of the International Conference on Logic Programming,
November 1999.
MIT Press.
[WWW]
Keyword(s): deductive databases,
debugging,
trace,
operational semantics,
multi-SLD-AL,
meta-interpreter,
substitution set,
instrumentation.
Abstract: |
Existing explanation systems for deductive databases show forests of proof trees. Although proof trees are often useful, they are only one possible interesting representation. We argue that an explanation system for deductive databases must be able to generate explanations at several levels of abstraction. One possible and well known technique to achieve this flexibility is to instrument meta-interpreters. It is, however, not often used because of its inefficiency. On the other hand, deductive databases often generate intermediate information stored in the physical database. This information can be considered as a low-level trace giving a faithful picture of what has happened at the relational level. The deductive reasoning is lost but can be very easily recovered by a meta-interpreter. In this article we describe a technique to generate explanations by integrating a relational trace and an instrumented meta-interpreter. The expensive aspects of meta-interpretation are reduced by the use of the trace which avoids many costly calculations. The flexibility of meta-interpretation is preserved, as illustrated by the generation of three different kinds of explanations: a box-oriented trace, a multi-SLD-AL tree and abstract AND trees. This technique enables powerful explanation systems to be implemented with very few modifications of the deductive database mechanism itself. |
@InProceedings{sm-iclp99,
Author = {S. Mallet and M. Ducassé},
Title = {Generating deductive database explanations},
Pages = {},
BookTitle = {Proceedings of the International Conference on Logic Programming},
Year = 1999,
Editor = {D. De Schreye},
Publisher = {MIT Press},
Month = {November},
Location = {mireille: whole proceedings},
url = {ftp://ftp.irisa.fr/local/lande/sm-md-iclp99.ps.gz},
keywords = {deductive databases, debugging, trace, operational semantics, multi-SLD-AL, meta-interpreter, substitution set, instrumentation},
abstract = {Existing explanation systems for deductive databases show forests of proof trees. Although proof trees are often useful, they are only one possible interesting representation. We argue that an explanation system for deductive databases must be able to generate explanations at several levels of abstraction. One possible and well known technique to achieve this flexibility is to instrument meta-interpreters. It is, however, not often used because of its inefficiency. On the other hand, deductive databases often generate intermediate information stored in the physical database. This information can be considered as a low-level trace giving a faithful picture of what has happened at the relational level. The deductive reasoning is lost but can be very easily recovered by a meta-interpreter. In this article we describe a technique to generate explanations by integrating a relational trace and an instrumented meta-interpreter. The expensive aspects of meta-interpretation are reduced by the use of the trace which avoids many costly calculations. The flexibility of meta-interpretation is preserved, as illustrated by the generation of three different kinds of explanations: a box-oriented trace, a multi-SLD-AL tree and abstract AND trees. This technique enables powerful explanation systems to be implemented with very few modifications of the deductive database mechanism itself.}
}
-
S. Mallet and M. Ducassé.
Myrtle: A set-oriented meta-interpreter driven by a ``relational'' trace for deductive database debugging.
In P. Flener, editor,
LOgic-based Program Synthesis and TRansformation,
pages 328-330,
1999.
Springer-Verlag, LNCS 1559.
Note: Résumé, version complète en RR-3598 INRIA.
@InProceedings{smallet99b,
Author = {S. Mallet and M. Ducassé},
Title = {Myrtle: A set-oriented meta-interpreter driven by a ``relational'' trace for deductive database debugging},
Pages = {328-330},
Editor = {P. Flener},
Booktitle = {{LO}gic-based Program Synthesis and TRansformation},
Year = {1999},
Publisher = {Springer-Verlag, LNCS 1559},
Note = {Résumé, version complète en RR-3598 INRIA}
}
-
D. Le Métayer,
V.-A. Nicolas,
and O. Ridoux.
Verification by testing for recursive program schemes.
In LOPSTR'99 (International Workshop on Logic Program Synthesis and Transformation),
1999.
Springer-Verlag, LNCS.
[WWW]
Keyword(s): Software engineering,
program verification,
white-box testing,
automated test data generation,
program analysis,
program schemes.
Abstract: |
In this paper, we explore the testing-verification relationship with the objective of mechanizing the generation of test data. We consider program classes defined as recursive program schemes and we show that complete and finite test data sets can be associated with such classes, that is to say that these test data sets allow us to distinguish every two different functions in these schemes. This technique is applied to the verification of simple properties of programs. |
@InProceedings{dlm-van-or-lopstr99,
author = {D. Le~Métayer and V.-A. Nicolas and O. Ridoux},
title = {Verification by testing for recursive program schemes},
booktitle = {LOPSTR'99 (International Workshop on Logic Program Synthesis and Transformation)},
year = {1999},
publisher = {Springer-Verlag, LNCS},
url = {http://www.irisa.fr/lande/vnicolas/articleLNCS99.pdf},
keywords = {Software engineering, program verification, white-box testing, automated test data generation, program analysis, program schemes},
abstract = {In this paper, we explore the testing-verification relationship with the objective of mechanizing the generation of test data. We consider program classes defined as recursive program schemes and we show that complete and finite test data sets can be associated with such classes, that is to say that these test data sets allow us to distinguish every two different functions in these schemes. This technique is applied to the verification of simple properties of programs.}
}
-
Olivier Ridoux,
Patrice Boizumault,
and Frédéric Malésieux.
Typed static analysis: application to groundness analysis of LambdaProlog and Prolog.
In A. Middeldorp and T. Sato, editors,
Proc. of the Int. Symp. on Functional and Logic Programming,
1999.
Springer.
@InProceedings{RID99,
Author={Olivier Ridoux and Patrice Boizumault and Frédéric Malésieux},
Title={Typed static analysis: application to groundness analysis of LambdaProlog and Prolog},
BookTitle={Proc. of the Int. Symp. on Functional and Logic Programming},
Year={1999},
Editor={A. Middeldorp and T. Sato},
Publisher={Springer}
}
-
Sébastien Ferré and Olivier Ridoux.
Une généralisation logique de l'analyse de concepts logique.
Technical Report RR-3820,
Inria, Institut National de Recherche en Informatique et en Automatique,
December 1999.
[WWW]
Keyword(s): concept analysis,
concept lattice,
logic,
context,
information systems,
querying,
browsing.
Abstract: |
Nous proposons une généralisation de l'analyse de concepts formels (ACF) dans laquelle les ensembles d'attributs sont remplacés par des expressions d'une logique presque arbitraire. Nous prouvons que toute l'ACF peut être reconstruite sur cette base. Nous montrons qu'à partir de toute logique utilisée à la place des ensembles d'attributs, on peut dériver une logique contextualisée qui prend en compte le contexte formel et qui est isomorphe au treillis de concepts. Nous comparons ensuite la généralisation de l'ACF aux extensions qui y ont déjà été apportées. Enfin, nous présentons nos perspectives d'application aux systèmes d'information. |
@TechReport{FerRid1999,
pages = "26 p.",
type = "Technical Report",
number = "RR-3820",
institution = "Inria, Institut National de Recherche en Informatique et en Automatique",
title = "Une généralisation logique de l'analyse de concepts logique",
author = "Sébastien Ferré and Olivier Ridoux",
year = "1999",
month = dec,
keywords = {concept analysis, concept lattice, logic, context, information systems, querying, browsing},
url = {http://www.inria.fr/rrrt/rr-3820.html},
abstract = {Nous proposons une généralisation de l'analyse de concepts formels (ACF) dans laquelle les ensembles d'attributs sont remplacés par des expressions d'une logique presque arbitraire. Nous prouvons que toute l'ACF peut être reconstruite sur cette base. Nous montrons qu'à partir de toute logique utilisée à la place des ensembles d'attributs, on peut dériver une logique contextualisée qui prend en compte le contexte formel et qui est isomorphe au treillis de concepts. Nous comparons ensuite la généralisation de l'ACF aux extensions qui y ont déjà été apportées. Enfin, nous présentons nos perspectives d'application aux systèmes d'information.},
annote = {FCA,logic,SI},
}
-
S. Mallet and M. Ducassé.
Myrtle: A set-oriented meta-interpreter driven by a ``relational'' trace for deductive database debugging.
Research Report RR-3598,
INRIA,
January 1999.
[WWW]
Keyword(s): deductive databases,
debugging,
trace,
multi-SLD-AL,
meta-interpreter,
substitution set,
instrumentation.
Abstract: |
Deductive databases manage large quantities of data and, in general, in a set-oriented way. The existing systems of explanation for deductive databases do not take these constraints into account. We propose a tracing technique which consists of integrating a "relational" trace and an instrumented meta-interpreter using substitution sets. The relational trace efficiently gives precise information about data extraction from the relational database. The meta-interpreter manages substitution sets and gives explanation on the deduction. The expensive aspects of meta-interpretation are reduced by the use of the trace which avoids many calculations. The flexibility of meta-interpretation is preserved. It allows different profiles of trace to be easily produced. |
@TechReport{sm-rr99,
Author = {S. Mallet and M. Ducassé},
Title = {Myrtle: A set-oriented meta-interpreter driven by a ``relational'' trace for deductive database debugging},
Institution = {INRIA},
Year = 1999,
Type = {Research Report},
Number = {RR-3598},
Month = {January},
url = {http://www.inria.fr/rrrt/rr-3598.html},
keywords = {deductive databases, debugging, trace, multi-SLD-AL, meta-interpreter, substitution set, instrumentation},
abstract = {Deductive databases manage large quantities of data and, in general, in a set-oriented way. The existing systems of explanation for deductive databases do not take these constraints into account. We propose a tracing technique which consists of integrating a "relational" trace and an instrumented meta-interpreter using substitution sets. The relational trace efficiently gives precise information about data extraction from the relational database. The meta-interpreter manages substitution sets and gives explanation on the deduction. The expensive aspects of meta-interpretation are reduced by the use of the trace which avoids many calculations. The flexibility of meta-interpretation is preserved. It allows different profiles of trace to be easily produced.}
}