Computing Reviews
Today's Issue Hot Topics Search Browse Recommended My Account Log In
Review Help
Search
PROUST: an automatic debugger for PASCAL programs
Johnson W., Soloway E. BYTE10 (4):179-190,1985.Type:Article
Date Reviewed: Aug 1 1985

PROUST is far more than what programmers usually mean by a “debugger.” It is not a tracing-dumping package, nor an interactive tool for use while a program is running. It analyzes a program statically, yet tries to find all the (non-syntactic) bugs in it. This is equivalent to solving the halting problem. The domain of programs is those written for an introductory programming course. PROUST uses a description of what the program is supposed to do, written in a notation (the “problem description language”) invented for that purpose. The article explains how PROUST works, and gives a summary of its performance analyzing 206 student programs written in response to a particular assignment (the “rainfall problem”). PROUST had impressive batting averages with this set of programs, both in finding and recognizing bugs and in avoiding false alarms. The authors claim, believably, that PROUST is not far from being good enough to be incorporated into a programming course curriculum.

The article is an instructive example and exposition of the use of artificial intelligence techniques. PROUST’s knowledge about programming is organized as two libraries: one collection of possible implementations of primitives in the problem description language (referred to as “plans” for implementing “goals”), and one collection of templates describing common bugs. In a system that has substantial knowledge sources such as these, the knowledge sources embody much of the character of the system and are more interesting than the pattern-matching algorithms that use them. I look forward to seeing, therefore, a description of these two knowledge sources and their evolution as PROUST is developed.

The skeptical reader will raise several questions that are not answered in the article. How does PROUST perform on problems other than the rainfall problem? Is the problem description language adequate? (The problem descriptions are supposed to “describe what the programs must do but not how they are supposed to do it”--a high-flown way of saying that the problem description language must be at a higher level than the problem programming language, PASCAL. But is it at a high enough level? Does it have enough primitives to be convenient for use by programming instructors? Is it even possible to have enough primitives?) Are there difficult problems to be solved in reducing the number of false alarms and in dealing more robustly with programs that PROUST does not fully understand? The present article is only a summary and gives results that are only preliminary, but the presentation is good and leads us to expect interesting developments in the future.

Reviewer:  B. Leverett Review #: CR109530
Bookmark and Share
 
Program Verification (I.2.2 ... )
 
 
Debugging Aids (D.2.5 ... )
 
 
Proust (D.2.5 ... )
 
 
Applications And Expert Systems (I.2.1 )
 
Would you recommend this review?
yes
no
Other reviews under "Program Verification": Date
Extraction of redundancy-free programs from constructive natural deduction proofs
Takayama Y. Journal of Symbolic Computation 12(1): 29-69, 1991. Type: Article
Oct 1 1992
Breeding software test cases with genetic algorithms
Berndt D., Fisher J., Johnson L., Pinglikar J., Watkins A.  Conference on System Sciences (Proceedings of the 36th Annual Hawaii International Conference on System Sciences (HICSS’03) - Track 9, Big Island, HI, Jan 6-9, 2003)338.12003. Type: Proceedings
Jun 3 2004
Modular Verification of Software Components in C
 IEEE Transactions on Software Engineering 30(6): 388-402, 2004. Type: Article
Jan 6 2005
more...

E-Mail This Printer-Friendly
Send Your Comments
Contact Us
Reproduction in whole or in part without permission is prohibited.   Copyright 1999-2024 ThinkLoud®
Terms of Use
| Privacy Policy