-
M. Ducassé and A.-M. Emde.
Opium: a debugging environment for Prolog development and debugging research.
ACM Software Engineering Notes,
16(1):54-59,
January 1991.
Note: Demonstration presented at the Fourth Symposium on Software Development Environments.
Abstract: |
Opium is an extensible debugging environment for PROLOG providing high-level debugging facilities for programmers and debugging experts. In the design of debuggers there are two tasks which are often mixed, extraction and analysis of debugging information. The aim of the extraction task is to collect the whole debugging information so that users do not miss any important information about their program. On the other hand, the aim of the analysis task is to restrict in an accurate way the amount of debugging information shown to the user so that the latter has to examine only the relevant parts. This task clearly depends on the debugging situation and, to our point of view, there is no general restriction which can be done a priori. However, the two tasks are usually mixed and hard-coded, the result is that not enough relevant information and too much useless information is displayed. In Opium the two tasks are clearly separated. The extraction module collects the whole debugging information (execution trace and program source) which is then available for the analysis module. The presentation concentrates on the analysis module, discussing the main aspects of Opium: programmability, high-level debugging, extensibility mechanisms, meta-debugging, support for end-users and debugging experts. |
@Article{de91d,
author = {M. Ducassé and A.-M. Emde},
title = {Opium: a debugging environment for {Prolog} development and debugging research},
journal = {ACM Software Engineering Notes},
year = {1991},
volume = {16},
number = {1},
pages = {54-59},
month = {January},
note = {Demonstration presented at the Fourth Symposium on Software Development Environments},
abstract = {Opium is an extensible debugging environment for PROLOG providing high-level debugging facilities for programmers and debugging experts. In the design of debuggers there are two tasks which are often mixed, extraction and analysis of debugging information. The aim of the extraction task is to collect the whole debugging information so that users do not miss any important information about their program. On the other hand, the aim of the analysis task is to restrict in an accurate way the amount of debugging information shown to the user so that the latter has to examine only the relevant parts. This task clearly depends on the debugging situation and, to our point of view, there is no general restriction which can be done a priori. However, the two tasks are usually mixed and hard-coded, the result is that not enough relevant information and too much useless information is displayed. In Opium the two tasks are clearly separated. The extraction module collects the whole debugging information (execution trace and program source) which is then available for the analysis module. The presentation concentrates on the analysis module, discussing the main aspects of Opium: programmability, high-level debugging, extensibility mechanisms, meta-debugging, support for end-users and debugging experts. }
}
-
P. Fradet and D. Le Métayer.
Compilation of functional languages by program transformation.
ACM Transactions on Programming Languages and Systems,
13(1):21--51,
1991.
[WWW
]
Abstract: |
One of the most important issues concerning functional languages is the efficiency and the correctness of their implementation. We focus on sequential implementations for conventional von Neumann computers. The compilation process is described in terms of program transformations in the functional framework. The original functional expression is transformed into a functional term that can be seen as a traditional machine code. The two main steps are the compilation of the computation rule by the introduction of continuation functions and the compilation of the environment management using combinators. The advantage of this approach is that we do not have to introduce an abstract machine, which makes correctness proofs much simpler. As far as efficiency is concerned, this approach is promising since many optimizations can be described and formally justified in the functional framework. |
@Article{TOPLAS91,
author = {P. Fradet and D. Le~Métayer},
url = {http://www.acm.org/pubs/articles/journals/toplas/1991-13-1/p21-fradet/p21-fradet.pdf},
title = {Compilation of functional languages by program transformation},
journal = {{ACM} Transactions on Programming Languages and Systems},
year = {1991},
volume = {13},
number = {1},
pages = {21--51},
abstract = {One of the most important issues concerning functional languages is the efficiency and the correctness of their implementation. We focus on sequential implementations for conventional von Neumann computers. The compilation process is described in terms of program transformations in the functional framework. The original functional expression is transformed into a functional term that can be seen as a traditional machine code. The two main steps are the compilation of the computation rule by the introduction of continuation functions and the compilation of the environment management using combinators. The advantage of this approach is that we do not have to introduce an abstract machine, which makes correctness proofs much simpler. As far as efficiency is concerned, this approach is promising since many optimizations can be described and formally justified in the functional framework.}
}
-
P. Brisset and O. Ridoux.
Naïve Reverse Can Be Linear.
In K. Furukawa, editor,
8th Int. Conf. Logic Programming,
pages 857--870,
1991.
MIT Press.
[WWW
] Keyword(s): LambdaProlog,
implementation,
function-lists,
higher-order unification..
Abstract: |
We propose a new implementation of logic programming with higher-order terms. In order to illustrate the properties of our implementation, we apply the coding of lists as functions to the context of logic programming. As a side-effect, we show that higher-order unification is a good tool for manipulating the function-lists. It appears that the efficiency of the program thus obtained relies critically upon the implementation of higher-order operations (unification and reduction). In particular, we show that a good choice for data-structures and reduction strategy yields a linear naïve reverse. |
@InProceedings{brisset:naivereverse:iclp:91,
author = {P. Brisset and O. Ridoux},
title = {Naïve Reverse Can Be Linear},
booktitle = {8th Int. Conf. Logic Programming},
editor = {K. Furukawa},
publisher = {MIT Press},
comment = {Paris, France},
pages = {857--870},
year = 1991,
abstract = {We propose a new implementation of logic programming with higher-order terms. In order to illustrate the properties of our implementation, we apply the coding of lists as functions to the context of logic programming. As a side-effect, we show that higher-order unification is a good tool for manipulating the function-lists. It appears that the efficiency of the program thus obtained relies critically upon the implementation of higher-order operations (unification and reduction). In particular, we show that a good choice for data-structures and reduction strategy yields a linear naïve reverse.},
keywords = {LambdaProlog, implementation, function-lists, higher-order unification.},
url = {ftp://ftp.irisa.fr/local/lande/pbor-iclp91.ps.Z}
}
-
M. Ducassé.
Abstract views of Prolog executions in Opium.
In V. Saraswat and K. Ueda, editors,
Proceedings of the International Logic Programming Symposium,
San Diego, USA,
pages 18-32,
October 1991.
MIT Press.
[WWW
]
Abstract: |
Opium is a system for analysing and debugging Prolog programs. Its kernel comprises an execution tracer and a programming language with a full set of primitives for trace and source analysis. In this paper we show the power of Opium for supporting abstract views of Prolog executions. Abstract views give high-level points of view about the execution. 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 and a kind of explanation for an expert system written in Prolog. |
@InProceedings{duc91c,
author = {M. Ducassé},
url = {ftp://ftp.irisa.fr/local/lande/md-ilps91.ps.gz},
title = {Abstract views of {Prolog} executions in {Opium}},
booktitle = {Proceedings of the International Logic Programming Symposium},
editor = {V. Saraswat and K. Ueda},
address = {San Diego, USA},
year = {1991},
month = {October},
publisher = {MIT Press},
pages = {18-32},
location = {was IR-LP-31-28},
abstract = {Opium is a system for analysing and debugging Prolog programs. Its kernel comprises an execution tracer and a programming language with a full set of primitives for trace and source analysis. In this paper we show the power of Opium for supporting abstract views of Prolog executions. Abstract views give high-level points of view about the execution. 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 and a kind of explanation for an expert system written in Prolog. }
}
-
P. Fradet.
Syntactic Detection of Single-Threading Using Continuations.
In Proc. of the 5th ACM Conf. on Functional Prog. Lang. and Comp. Arch.,
volume 523 of LNCS,
Cambridge, MA, USA,
pages 241-258,
August 1991.
Springer-Verlag.
[WWW
] Keyword(s): Globalization,
single-threading,
in-place update,
CPS conversion..
Abstract: |
We tackle the problem of detecting global variables in functional programs. We present syntactic criteria for single-threading which improves upon previous solutions (both syntactic and semantics-based) in that it applies to higher-order languages and to most sequential evaluation strategies. The main idea of our approach lies in the use of continuations. One advantage of continuation expressions is that evaluation ordering is made explicit in the syntax of expressions. So, syntactic detection of single-threading is simpler and more powerful on continuation expressions. We present the application of the analysis to the compilation of functional languages, semantics-directed compiler generation and globalization-directed transformations (i.e. transforming non-single-threaded expressions into single-threaded ones). Our results can also be turned to account to get single-threading criteria on regular lambda-expressions for different sequential evaluation orders. |
@InProceedings{fpca91,
author = {P. Fradet},
title = {Syntactic Detection of Single-Threading Using Continuations},
booktitle = {Proc. of the 5th ACM Conf. on Functional Prog. Lang. and Comp. Arch.},
year = 1991,
url = {ftp://ftp.irisa.fr/local/lande/pf-fpca91.ps.Z},
keywords = {Globalization, single-threading, in-place update, CPS conversion.},
abstract = {We tackle the problem of detecting global variables in functional programs. We present syntactic criteria for single-threading which improves upon previous solutions (both syntactic and semantics-based) in that it applies to higher-order languages and to most sequential evaluation strategies. The main idea of our approach lies in the use of continuations. One advantage of continuation expressions is that evaluation ordering is made explicit in the syntax of expressions. So, syntactic detection of single-threading is simpler and more powerful on continuation expressions. We present the application of the analysis to the compilation of functional languages, semantics-directed compiler generation and globalization-directed transformations (i.e. transforming non-single-threaded expressions into single-threaded ones). Our results can also be turned to account to get single-threading criteria on regular lambda-expressions for different sequential evaluation orders.},
volume = 523,
series = {LNCS},
publisher = {Springer-Verlag},
address = {Cambridge, MA, USA},
month = {August},
pages = {241-258}
}