Logic Programming

While logic pro­gram­ming has fallen out of fash­ion, the siz­able research pro­gram around it in the 1980s and 90s has left us many inter­est­ing threads to poten­tially pick back up. In par­tic­u­lar, researchers devel­oped a num­ber of tools to facil­i­tate debug­ging of Pro­log pro­grams. Sev­eral sys­tems visu­al­ized And–Or trees that rep­re­sented the exe­cu­tion trace of a Pro­log pro­gram: the Dewlap debug­ger 8, the Trans­par­ent Pro­log Machine 11, and cyclic And–Or graphs 30. shows exam­ples of dia­grams from the lat­ter two sys­tems. Other Pro­log debug­gers like Opium 9 focused on abstract­ing data and con­trol-flow within large exe­cu­tion traces.

These trees pro­vide some guid­ance in how to com­pactly visu­al­ize var­i­ous aspects of a logic pro­gram trace, such as uni­fi­ca­tion and back­track­ing. The Argus sys­tem adopts the And–Or struc­ture of the tree but puts a larger empha­sis on scal­ing. Large-scale visu­al­iza­tion become illeg­i­ble quickly and we need to make sure devel­op­ers can find the infor­ma­tion they’re look­ing for as quick as pos­si­ble. The idea is that with a quick scan they already have a bet­ter idea of what went wrong.

For exam­ple, the AORTA dia­grams from Eisen­stadt include small icons on the nodes and edges that encode con­trol flow direc­tion and uni­fi­ca­tion through the tree. These icons are tremen­dously help­ful in the given exam­ple () but do not scale well for larger prob­lems. Argus puts a much larger empha­sis on hid­ing unnec­es­sary infor­ma­tion by default, but giv­ing devel­op­ers the set­tings to opt-in should they choose. Later work on the Trans­par­ent Pro­log Machine empha­sized help­ing users ori­ent them­selves while inspect­ing a large tree, and some tech­niques may be appro­pri­ate for future work.