Declarative debugging of abstract data types in Gödel
Modern software engineering uses abstract data types to allow modular programming. When debugging, abstract data types cause problems because the user does not understand the implementation of the type. This is particularly true in declarative debugging where users must determine the validity of an atom. As the user of the type does not know how the type is implemented the user is unable to determine its validity when presented with the implementation. Frequently, the user visualises a structure which the type represents. This view can be used when displaying terms of this type during debugging. We introduce the concept of a representer, which, establishes an equivalence between a term and this view. During debugging, the representers are used to translate terms to and from their view. When inputting abstract data types, the representer will produce the hidden term from the visible term the user gave. When outputting abstract data types, the representer will produce a visible term from the hidden term. We also extend the idea of representers to be able to handle large data efficiently.
Unable to display preview. Download preview PDF.
- 1.E. Av-Ron. Top-down diagnosis of Prolog programs. Masters Thesis, Weizmann Institute of Science, 1984.Google Scholar
- 2.P. Hill and J. W. Lloyd. The Gödel programming language. Technical Report CSTR-92-27, University of Bristol, October 1992 (Revised May 1993).Google Scholar
- 3.Yossi Lichtenstein and Ehud Shapiro. Abstract algorithmic debugging. In Robert A. Kowalski and Kenneth A. Bowen, editors, Proceedings of the Fifth International Conference and Symposium on Logic Programming, pages 512–531, Seattle, 1988. ALP, IEEE, The MIT Press.Google Scholar
- 4.J.W. Lloyd. Foundations of Logic Programming. Springer-Verlag, 1987.Google Scholar
- 5.Lee Naish. Declarative debugging of lazy functional programs. In Proceedings of the Post Conference Workshop on Logic Programming Environments (Joint International Conference and Symposium on Logic Programming), Washington, November 1992.Google Scholar
- 6.S. Renner. Location of logical errors on Pascal programs with an appendix on implementation problems in Waterloo Prolog/c. Technical Report UIUCDCS-F-82-896, Department of Computer Science, Univeristy of Illinois at Urbana, Champaign-Urbana, Illinois, April 1982.Google Scholar