A framework for the principled debugging of Prolog programs: how to debug non-terminating programs
Abstract: "The search for better Prolog debugging environments has taken a number of different paths of which three are particularly important: improvements to monitoring tools (notably the Transparent Prolog Machine (Eisenstadt & Brayshaw, 1987)), providing for greater user control over th...
Gespeichert in:
| Hauptverfasser: | , , |
|---|---|
| Format: | Buch |
| Sprache: | English |
| Veröffentlicht: |
Edinburgh
1990
|
| Schriftenreihe: | University <Edinburgh> / Department of Artificial Intelligence: DAI research paper
472 |
| Schlagworte: | |
| Zusammenfassung: | Abstract: "The search for better Prolog debugging environments has taken a number of different paths of which three are particularly important: improvements to monitoring tools (notably the Transparent Prolog Machine (Eisenstadt & Brayshaw, 1987)), providing for greater user control over the debugging process (notably as in Opium p+ s (Ducasse, 1988)), and partially automating the debugging process (notably in (Pereira, 1986; Lloyd, 1986; Pereira & Calejo, 1988; Naish, 1988)). A serious problem associated with this activity lies in providing a principled conceptual framework within which the programmer can work with a number of different debugging tools Here, we outline a framework that we have developed for the debugging of Prolog programs. We point out the relationship that holds between this framework and each of these three advances in debugging. In order to demonstrate how the framework can be used, we explore an issue that has received relatively little attention recently: the run-time detection of programs that do not appear to terminate. Our analysis of (apparent) non-termination is based on a four level Bug Description Framework that we have developed. This analysis goes further than the consideration of programs that would normally be regarded as 'looping' We describe a debugging strategy in conjunction with a range of monitoring tools that provide greater assistance than currently found. We indicate the increased efficiency that would be gained through a close-coupling of the program construction and execution phases. From this analysis, we see that current (non-graphical) debugging tools do not provide the necessary help to deal with the case of (apparent) non-termination. We also note that even a graphical debugger such as TPM (Eisenstadt & Brayshaw, 1987) does not provide all the desired assistance that we would like. |
| Beschreibung: | 30 S. |
Internformat
MARC
| LEADER | 00000nam a2200000 cb4500 | ||
|---|---|---|---|
| 001 | BV010451893 | ||
| 003 | DE-604 | ||
| 005 | 19980216 | ||
| 007 | t | ||
| 008 | 951026s1990 |||| 00||| engod | ||
| 035 | |a (OCoLC)23158959 | ||
| 035 | |a (DE-599)BVBBV010451893 | ||
| 040 | |a DE-604 |b ger |e rakddb | ||
| 041 | 0 | |a eng | |
| 049 | |a DE-91G | ||
| 084 | |a DAT 330f |2 stub | ||
| 084 | |a DAT 366f |2 stub | ||
| 100 | 1 | |a Brna, Paul |e Verfasser |4 aut | |
| 245 | 1 | 0 | |a A framework for the principled debugging of Prolog programs |b how to debug non-terminating programs |c Paul Brna, Alan Bundy and Helen Pain |
| 264 | 1 | |a Edinburgh |c 1990 | |
| 300 | |a 30 S. | ||
| 336 | |b txt |2 rdacontent | ||
| 337 | |b n |2 rdamedia | ||
| 338 | |b nc |2 rdacarrier | ||
| 490 | 1 | |a University <Edinburgh> / Department of Artificial Intelligence: DAI research paper |v 472 | |
| 520 | 3 | |a Abstract: "The search for better Prolog debugging environments has taken a number of different paths of which three are particularly important: improvements to monitoring tools (notably the Transparent Prolog Machine (Eisenstadt & Brayshaw, 1987)), providing for greater user control over the debugging process (notably as in Opium p+ s (Ducasse, 1988)), and partially automating the debugging process (notably in (Pereira, 1986; Lloyd, 1986; Pereira & Calejo, 1988; Naish, 1988)). A serious problem associated with this activity lies in providing a principled conceptual framework within which the programmer can work with a number of different debugging tools | |
| 520 | 3 | |a Here, we outline a framework that we have developed for the debugging of Prolog programs. We point out the relationship that holds between this framework and each of these three advances in debugging. In order to demonstrate how the framework can be used, we explore an issue that has received relatively little attention recently: the run-time detection of programs that do not appear to terminate. Our analysis of (apparent) non-termination is based on a four level Bug Description Framework that we have developed. This analysis goes further than the consideration of programs that would normally be regarded as 'looping' | |
| 520 | 3 | |a We describe a debugging strategy in conjunction with a range of monitoring tools that provide greater assistance than currently found. We indicate the increased efficiency that would be gained through a close-coupling of the program construction and execution phases. From this analysis, we see that current (non-graphical) debugging tools do not provide the necessary help to deal with the case of (apparent) non-termination. We also note that even a graphical debugger such as TPM (Eisenstadt & Brayshaw, 1987) does not provide all the desired assistance that we would like. | |
| 650 | 7 | |a Computer software |2 sigle | |
| 650 | 4 | |a Debugging in computer science | |
| 650 | 4 | |a Prolog (Computer program language) | |
| 700 | 1 | |a Bundy, Alan |e Verfasser |4 aut | |
| 700 | 1 | |a Pain, Helen |e Verfasser |4 aut | |
| 810 | 2 | |a Department of Artificial Intelligence: DAI research paper |t University <Edinburgh> |v 472 |w (DE-604)BV010450646 |9 472 | |
| 999 | |a oai:aleph.bib-bvb.de:BVB01-006964885 | ||
Datensatz im Suchindex
| _version_ | 1804124884928823296 |
|---|---|
| any_adam_object | |
| author | Brna, Paul Bundy, Alan Pain, Helen |
| author_facet | Brna, Paul Bundy, Alan Pain, Helen |
| author_role | aut aut aut |
| author_sort | Brna, Paul |
| author_variant | p b pb a b ab h p hp |
| building | Verbundindex |
| bvnumber | BV010451893 |
| classification_tum | DAT 330f DAT 366f |
| ctrlnum | (OCoLC)23158959 (DE-599)BVBBV010451893 |
| discipline | Informatik |
| format | Book |
| fullrecord | <?xml version="1.0" encoding="UTF-8"?><collection xmlns="http://www.loc.gov/MARC21/slim"><record><leader>03146nam a2200385 cb4500</leader><controlfield tag="001">BV010451893</controlfield><controlfield tag="003">DE-604</controlfield><controlfield tag="005">19980216 </controlfield><controlfield tag="007">t</controlfield><controlfield tag="008">951026s1990 |||| 00||| engod</controlfield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(OCoLC)23158959</subfield></datafield><datafield tag="035" ind1=" " ind2=" "><subfield code="a">(DE-599)BVBBV010451893</subfield></datafield><datafield tag="040" ind1=" " ind2=" "><subfield code="a">DE-604</subfield><subfield code="b">ger</subfield><subfield code="e">rakddb</subfield></datafield><datafield tag="041" ind1="0" ind2=" "><subfield code="a">eng</subfield></datafield><datafield tag="049" ind1=" " ind2=" "><subfield code="a">DE-91G</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">DAT 330f</subfield><subfield code="2">stub</subfield></datafield><datafield tag="084" ind1=" " ind2=" "><subfield code="a">DAT 366f</subfield><subfield code="2">stub</subfield></datafield><datafield tag="100" ind1="1" ind2=" "><subfield code="a">Brna, Paul</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="245" ind1="1" ind2="0"><subfield code="a">A framework for the principled debugging of Prolog programs</subfield><subfield code="b">how to debug non-terminating programs</subfield><subfield code="c">Paul Brna, Alan Bundy and Helen Pain</subfield></datafield><datafield tag="264" ind1=" " ind2="1"><subfield code="a">Edinburgh</subfield><subfield code="c">1990</subfield></datafield><datafield tag="300" ind1=" " ind2=" "><subfield code="a">30 S.</subfield></datafield><datafield tag="336" ind1=" " ind2=" "><subfield code="b">txt</subfield><subfield code="2">rdacontent</subfield></datafield><datafield tag="337" ind1=" " ind2=" "><subfield code="b">n</subfield><subfield code="2">rdamedia</subfield></datafield><datafield tag="338" ind1=" " ind2=" "><subfield code="b">nc</subfield><subfield code="2">rdacarrier</subfield></datafield><datafield tag="490" ind1="1" ind2=" "><subfield code="a">University <Edinburgh> / Department of Artificial Intelligence: DAI research paper</subfield><subfield code="v">472</subfield></datafield><datafield tag="520" ind1="3" ind2=" "><subfield code="a">Abstract: "The search for better Prolog debugging environments has taken a number of different paths of which three are particularly important: improvements to monitoring tools (notably the Transparent Prolog Machine (Eisenstadt & Brayshaw, 1987)), providing for greater user control over the debugging process (notably as in Opium p+ s (Ducasse, 1988)), and partially automating the debugging process (notably in (Pereira, 1986; Lloyd, 1986; Pereira & Calejo, 1988; Naish, 1988)). A serious problem associated with this activity lies in providing a principled conceptual framework within which the programmer can work with a number of different debugging tools</subfield></datafield><datafield tag="520" ind1="3" ind2=" "><subfield code="a">Here, we outline a framework that we have developed for the debugging of Prolog programs. We point out the relationship that holds between this framework and each of these three advances in debugging. In order to demonstrate how the framework can be used, we explore an issue that has received relatively little attention recently: the run-time detection of programs that do not appear to terminate. Our analysis of (apparent) non-termination is based on a four level Bug Description Framework that we have developed. This analysis goes further than the consideration of programs that would normally be regarded as 'looping'</subfield></datafield><datafield tag="520" ind1="3" ind2=" "><subfield code="a">We describe a debugging strategy in conjunction with a range of monitoring tools that provide greater assistance than currently found. We indicate the increased efficiency that would be gained through a close-coupling of the program construction and execution phases. From this analysis, we see that current (non-graphical) debugging tools do not provide the necessary help to deal with the case of (apparent) non-termination. We also note that even a graphical debugger such as TPM (Eisenstadt & Brayshaw, 1987) does not provide all the desired assistance that we would like.</subfield></datafield><datafield tag="650" ind1=" " ind2="7"><subfield code="a">Computer software</subfield><subfield code="2">sigle</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Debugging in computer science</subfield></datafield><datafield tag="650" ind1=" " ind2="4"><subfield code="a">Prolog (Computer program language)</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Bundy, Alan</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="700" ind1="1" ind2=" "><subfield code="a">Pain, Helen</subfield><subfield code="e">Verfasser</subfield><subfield code="4">aut</subfield></datafield><datafield tag="810" ind1="2" ind2=" "><subfield code="a">Department of Artificial Intelligence: DAI research paper</subfield><subfield code="t">University <Edinburgh></subfield><subfield code="v">472</subfield><subfield code="w">(DE-604)BV010450646</subfield><subfield code="9">472</subfield></datafield><datafield tag="999" ind1=" " ind2=" "><subfield code="a">oai:aleph.bib-bvb.de:BVB01-006964885</subfield></datafield></record></collection> |
| id | DE-604.BV010451893 |
| illustrated | Not Illustrated |
| indexdate | 2024-07-09T17:52:46Z |
| institution | BVB |
| language | English |
| oai_aleph_id | oai:aleph.bib-bvb.de:BVB01-006964885 |
| oclc_num | 23158959 |
| open_access_boolean | |
| owner | DE-91G DE-BY-TUM |
| owner_facet | DE-91G DE-BY-TUM |
| physical | 30 S. |
| publishDate | 1990 |
| publishDateSearch | 1990 |
| publishDateSort | 1990 |
| record_format | marc |
| series2 | University <Edinburgh> / Department of Artificial Intelligence: DAI research paper |
| spelling | Brna, Paul Verfasser aut A framework for the principled debugging of Prolog programs how to debug non-terminating programs Paul Brna, Alan Bundy and Helen Pain Edinburgh 1990 30 S. txt rdacontent n rdamedia nc rdacarrier University <Edinburgh> / Department of Artificial Intelligence: DAI research paper 472 Abstract: "The search for better Prolog debugging environments has taken a number of different paths of which three are particularly important: improvements to monitoring tools (notably the Transparent Prolog Machine (Eisenstadt & Brayshaw, 1987)), providing for greater user control over the debugging process (notably as in Opium p+ s (Ducasse, 1988)), and partially automating the debugging process (notably in (Pereira, 1986; Lloyd, 1986; Pereira & Calejo, 1988; Naish, 1988)). A serious problem associated with this activity lies in providing a principled conceptual framework within which the programmer can work with a number of different debugging tools Here, we outline a framework that we have developed for the debugging of Prolog programs. We point out the relationship that holds between this framework and each of these three advances in debugging. In order to demonstrate how the framework can be used, we explore an issue that has received relatively little attention recently: the run-time detection of programs that do not appear to terminate. Our analysis of (apparent) non-termination is based on a four level Bug Description Framework that we have developed. This analysis goes further than the consideration of programs that would normally be regarded as 'looping' We describe a debugging strategy in conjunction with a range of monitoring tools that provide greater assistance than currently found. We indicate the increased efficiency that would be gained through a close-coupling of the program construction and execution phases. From this analysis, we see that current (non-graphical) debugging tools do not provide the necessary help to deal with the case of (apparent) non-termination. We also note that even a graphical debugger such as TPM (Eisenstadt & Brayshaw, 1987) does not provide all the desired assistance that we would like. Computer software sigle Debugging in computer science Prolog (Computer program language) Bundy, Alan Verfasser aut Pain, Helen Verfasser aut Department of Artificial Intelligence: DAI research paper University <Edinburgh> 472 (DE-604)BV010450646 472 |
| spellingShingle | Brna, Paul Bundy, Alan Pain, Helen A framework for the principled debugging of Prolog programs how to debug non-terminating programs Computer software sigle Debugging in computer science Prolog (Computer program language) |
| title | A framework for the principled debugging of Prolog programs how to debug non-terminating programs |
| title_auth | A framework for the principled debugging of Prolog programs how to debug non-terminating programs |
| title_exact_search | A framework for the principled debugging of Prolog programs how to debug non-terminating programs |
| title_full | A framework for the principled debugging of Prolog programs how to debug non-terminating programs Paul Brna, Alan Bundy and Helen Pain |
| title_fullStr | A framework for the principled debugging of Prolog programs how to debug non-terminating programs Paul Brna, Alan Bundy and Helen Pain |
| title_full_unstemmed | A framework for the principled debugging of Prolog programs how to debug non-terminating programs Paul Brna, Alan Bundy and Helen Pain |
| title_short | A framework for the principled debugging of Prolog programs |
| title_sort | a framework for the principled debugging of prolog programs how to debug non terminating programs |
| title_sub | how to debug non-terminating programs |
| topic | Computer software sigle Debugging in computer science Prolog (Computer program language) |
| topic_facet | Computer software Debugging in computer science Prolog (Computer program language) |
| volume_link | (DE-604)BV010450646 |
| work_keys_str_mv | AT brnapaul aframeworkfortheprincipleddebuggingofprologprogramshowtodebugnonterminatingprograms AT bundyalan aframeworkfortheprincipleddebuggingofprologprogramshowtodebugnonterminatingprograms AT painhelen aframeworkfortheprincipleddebuggingofprologprogramshowtodebugnonterminatingprograms |