L. Byrd. Understanding the control flow of prolog programs. In S.-A. Tarnlund, editor, Proceedings of the Workshop on Logic Programming, 1980.  Home/Search   Document Not in Database   Summary   Related Articles   Check

....Return the chronological number of the current line in the sequence of all trace lines. CurrCall 1 Return the call number of the current line. CurrDepth 1 Return the execution depth of the current line. CurrPort 1 Return the debug port of the current line according to Byrd s box model [4]. CurrPred 1 Return the name of the predicate executed at the current line. CurrArity 1 Return the arity of the predicate executed in the current line. Leap 0 Search forward for a call to a predicate on which a spypoint has been set. FGet 10 Search forwards for a trace line matching some given ....

L. Byrd. Understanding the control flow of Prolog programs. In Logic Programming Workshop, Debrecen, 1980.

....instrumentation. We will also delay discussion of taking the profiling measurements themselves until section 5.3.11. The current call site dynamic global variable must be updated whenever control passes from one procedure to another. The standard box model for the execution of logic programs [16] classifies control transfers into four categories: call, exit, redo and fail. Exit and fail represent successful and unsuccessful returns respectively, while redo represents backtracking back into a call. Each of these methods of control transfer is called a port in logic programming ....

Lawrence Byrd. Understanding the control flow of Prolog programs. In Proceedings of the 1980.

....di#cult due to their complex execution mechanism. Two di#erent intertwined control flows (AND and OR) cause a complex execution trace that cannot be followed easily in order to understand the actual reason for termination or non termination. The commonly used procedure box model introduced by [2] for debugging, produces a huge amount of detailed traces with no relevance to the actual termination behavior. Similarly, the notion of proof trees is not able to explain non termination succinctly. Current research in termination analysis of logic programs focuses on the construction of ....

....the program itself. For a program with n program points there are P(p(P, Q) 2 possible failure slices. Example 1. For predicate list invdi# 3 the set of program points p(P, Q) is the set of integers 1, 2, 3, 4, 5 . On the right, the slice 2, 4 is shown. P0 list invdi#(Xs, [1,2,3], P5 list invdi#( Xs, Xs) P1 list invdi#(Es, Xs0, Xs1) P3 Xs1 = E Xs] P4 list invdi#(Xs, 1,2,3] false. list invdi#( Xs, Xs) false. list invdi#(Es, Xs0, Xs1) false, Xs1 = E Xs] Definition 3 (Partial order) A failure slice S is smaller than T if S ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. Logic Programming Workshop, Debrecen, Hungary, 1980.

....node child fails. The Dataflow points represent di#erent entries into the AND OR nodes, each entry corresponding to a di#erent state of the computation. The dataflow points associated with each node are shown in following table (observe their similarity to ports in Byrd s Prolog execution model [8]) DATAFLOW POINT STATE OF COMPUTATION entry e dest getting first tuple of node backtrack b dest getting next tuple of node success s dest a tuple has been generated fail f dest no more tuples can be generated 2 Similar to a C virtual function 19 A dataflow point of a node can be ....

Byrd, L., "Understanding the Control Flow of Prolog Programs," in Proc. of the Logic Programming Workshop, 1980.

....difficult due to their complex execution mechanism. Two different intertwined control flows (AND and OR) cause a complex execution trace that cannot be followed easily in order to understand the actual reason for termination or non termination. The commonly used procedure box model introduced by [2] for debugging, produces a huge amount of detailed traces with no relevance to the actual termination behavior. Similarly, the notion of proof trees is not able to explain non termination succinctly. Current research in termination analysis of logic programs focuses on the construction of ....

....program itself. For a program with n program points there are jP(p(P; Q) j = 2 n possible failure slices. Example 1. For predicate list invdiff 3 the set of program points p(P; Q) is the set of integers f0; 1; 2; 3; 4; 5g. On the right, the slice f0; 2; 4g is shown. P0 list invdiff(Xs, [1,2,3], P5 list invdiff( Xs, Xs) P1 list invdiff( EjEs] Xs0, Xs) P2 list invdiff(Es, Xs0, Xs1) P3 Xs1 = EjXs] P4 list invdiff(Xs, 1,2,3] false. list invdiff( Xs, Xs) false. list invdiff( EjEs] Xs0, Xs) list invdiff(Es, Xs0, Xs1) false, Xs1 = EjXs] ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. Logic Programming Workshop, Debrecen, Hungary, 1980.

....(which is in our view more readable than the usual denotational approach via lambda calculus, offers access to intermediate states, etc. and a lean mathematical (i.e. denotational) model. After introducing the semantics, we give several examples, including a definition of the Byrd s semantics [Byr80] in our own. 2 Representing derivation states and answer substitutions A top level goal G 0 we represent as DJG 0 K with an operational reading start the derivation of G 0 . The D is the derivation operator, D operator for short. Its argument in brackets represents the current goal. The fat ....

....line from below, how the suffix criterion swipes clean the continuations up to, and including, the one for repeat . This is essential for the termination of the loop. 5 Specifying the Byrd model A classical challenge for each new Prolog semantics is to specify the Byrd box model of Prolog [Byr80], see e.g. BR95] JDR00] In our approach the Byrd model can be specified (or shall we say: incorporated, as an additional functionality) very naturally. Looking at the rules for user defined predicates (Sec. 3.1) the first rule obviously captures the sole entry point of a goal, so it is the ....

[Article contains additional citation context not shown here]

Lawrence Byrd. Understanding the control flow of Prolog programs. In S. A. Tarnlund, editor, Proc. of the Logic Programming Workshop, pages 127--138, Debrecen, Hungary, 1980. Also as D. A. I. Research Paper No. 151.

....illustrations. If an annotation does not hold (with respect to the given program and a goal) our runtime checker Nope will issue a warning. The default warning in Nope shows the violated annotation, with its arrow broken. For the safe negation example it would look like NOPE call member(A,[1,2]) 6) ground(member(A, 1,2] This can be overridden via an explicit use of the else 2 utility (defined on page 9) call X ) ground(X) else write(floundering) customizing the warning into NOPE floundering . Also, the warning handler of Nope has different severity levels. For example, ....

....does not hold (with respect to the given program and a goal) our runtime checker Nope will issue a warning. The default warning in Nope shows the violated annotation, with its arrow broken. For the safe negation example it would look like NOPE call member(A, 1,2] 6) ground(member(A,[1,2]) This can be overridden via an explicit use of the else 2 utility (defined on page 9) call X ) ground(X) else write(floundering) customizing the warning into NOPE floundering . Also, the warning handler of Nope has different severity levels. For example, the utility bark 0 ....

[Article contains additional citation context not shown here]

Lawrence Byrd. Understanding the control flow of Prolog programs. In S. A. Trnlund, editor, Proc. of the Logic Programming Workshop, pages 127--138, Debrecen, Hungary, 1980. Also as D. A. I. Research Paper No. 151.

....transformation scheme of Curry into Prolog programs, the use of Prolog as a target language has further advantages. A high level implementation more easily accomodates the inclusion 183 of additional features. For instance, the implementation of a standard program tracer w.r.t. Byrd s box model [6] requires only the addition of four clauses to each program and two predicate calls for each implemented function. The most important advantage is the reuse of existing constraint solvers available in Prolog, as shown in Section 3.3. Thus, with a limited e ort, we obtain a usable implementation of ....

L. Byrd. Understanding the Control Flow of Prolog Programs. In Proc. of the Workshop on Logic Programming, Debrecen, 1980.

....with various Prolog trace models, we translate these specifications into Prolog. This translation leads to a Prolog interpreter that performs execution traces. We have hence a formal framework to specify, prototype, and validate trace models for Prolog. 1 Introduction Byrd s box model [9] is a very fine grained Prolog execution model that provides a precise but verbose image of the execution. It is sometimes stated that it should not be used in debuggers. Whether Byrd s trace is a proper output format for an end user may indeed be discussed. A trace, however, can be the basis of ....

....and thus we insert a redo event just before it. If the goal fails, its failure continuation will be executed; hence we insert a fail event just before it. Equation 1.10 specifies how to translate the cut. Since the way the cut should be traced is not described in Byrd s original article [9], we handle it the same way as any other atomic goal, and we instrument Equation 1.10 in the same manner as Equation 1.9. The result of a call to Byrd query [ P ] is a list of events, where an event is either an atom yes or no, or a tuple. Here, the tuples are triples containing a port, a ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, 1980.

....contain as many details as it is possible to extract cheaply because reconstructing events is very costly [16] Then the analysis module, built for example on top of the mechanism described in the current paper, should provide whatever views are required by users. For example, the model of Byrd [5] shows the events in an order which is different from the order in which they actually occur in the execution. Backtracking in a subgoal of a goal g is traced as if backtracking was occurring first on g. We find this misleading, but even if some users like this story it should not be the extracted ....

....our view, which model is actually extracted is independent of what programmers need. What is important is to be able to provide different views afterwards. The abstract views we developed [10] are an illustration of this approach. We use an extracted model close to the four port model of Byrd [5]. The main difference is that the events are traced in chronological order. The actual ports have no influence on the mechanisms described in this paper and there is no need to go into much detail. Briefly, the four ports are four different types of events related to goals: call , exit , fail ....

L. Byrd. Understanding the control flow of Prolog programs. In Logic Programming Workshop, Debrecen, 1980.

....mechanism used is the explicit procedure call. Implicit calls between other paradigms Table 2. Explicit control transfer in different paradigms. Paradigm Transfer mode Imperative Procedure call Functional Eager reduction Logic Predicate invocation through its call port (c.f. Byrd model [2]) Table 3. Implicit control transfer in different paradigms. Paradigm Transfer mode Imperative Invocation of an interrupt handler Functional reduction of a suspended expression in a lazy implementation Logic Predicate invocation through its redo port (backtracking) CSP A process is awaken as ....

Byrd L (1980) Understanding the control flow of Prolog programs. In Logic Programming Workshop, Debrecen.

....by handing the more tricky properties over to Prolog. For the benefit of the user, as well as for automation of debugging, it is advantageous to start from an explicit execution model. The model should ideally be simple and complete. One such model happens to be generally known. The 4 port model [2], which is the basis of the standard Prolog debugger, is a complete execution model of Prolog, in the sense of entailing every aspect of Prolog execution of necessity for verification, and therefore all the information one might need. This model maps a query Q to its standard trace T (Q) which is ....

.... a query Q to its standard trace T (Q) which is a sequence of events of the form Port F(T 1 ; TN ) where Port may be one of fcall, exit, fail, redog, F N are predicates, T are terms, representing the atomary steps of the Prolog interpreter during the execution of the query Q (as defined in [2], 18] A consequence of such expressive power is also that the amount of information generated by this model be overwhelming, so that its straightforward use as in the standard 4 port debugger is often considered as too low level. One line of research addressing this problem is trace analysis ....

[Article contains additional citation context not shown here]

Lawrence Byrd. Understanding the control flow of Prolog programs. In S. A. Trnlund, editor, Proc. of the Logic Programming Workshop, pages 127--138, Debrecen, Hungary, 1980. Also as D. A. I. Research Paper No. 151.

....symptoms, which are the ones detected by compile time checking. 6 It is out of the scope of this paper to discuss how program diagnosis should be performed. However, techniques such as declarative debugging [41,6,18,19] abstract debugging [13,14] or more traditional interactive debuggers [11,20] may be applied. 6 rewritten as checked assertions; in the second case abstract symptoms are detected, the corresponding assertions are rewritten as false assertions, and error messages are presented to the user. Once again, diagnosis should be started, for example using abstract diagnosis ....

L. Byrd. Understanding the Control Flow of Prolog Programs. In S.-A. Tarnlund, editor, Workshop on Logic Programming, Debrecen, 1980.

....by some students when given a procedural interpretation. A useful exercise for Prolog learners, both for gaining an understanding of how Prolog works and for understanding or debugging their own programs, is tracing execution. One possible tool for tracing is the common four port debugger [Byrd80]. However, this debugger has certain limitations because it provides information in low bandwidth textual form; roughly speaking, it prints the procedure call showing bound variables, as well as other information describing the state of the computation. Novice users find this unsatisfying. They ....

L. Byrd, "Understanding the Control Flow of PROLOG Programs", Proceedings of the Logic Programming

....to a goal. It is the depth of the goal in the proof tree, namely the number of its ancestor goals 1. ffl Event type or port (port) attached to an event. The different Mercury event types are as follows. We distinguish between external events which are the traditional ports introduced by Byrd [1], and the internal events which refers to what is occurring inside a procedure. External events call a new procedure is invoked exit the current procedure succeeds fail the current procedure fails redo another solution for the current procedure is asked for on backtracking, and a ....

....is in the else branch of an if then else, which is in the third conjunction of the current goal. 2.3 An example of Mercury event The event structure is illustrated by Figure 1. The displayed structure is related to an event of the execution of the qsort program which sorts the list of integers [3, 1, 2] using a quick sort algorithm. The full code of qsort.m is given in Appendix A. The information contained in that structure indicates that procedure qsort:partition 4 0 is currently invoked, it is the 10 th trace events being generated, the 6 th goal being invoked, and it has 4 th ancestors ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, Debrecen, Hungary, 1980.

....of our transformation scheme of Curry into Prolog programs, the use of Prolog as a target language has further advantages. A highlevel implementation more easily accomodates the inclusion of additional features. For instance, the implementation of a standard program tracer w.r.t. Byrd s box model [6] requires only the addition of four clauses to each program and two predicate calls for each implemented function. The most important advantage is the reuse of existing constraint solvers available in Prolog, as shown in Section 3.3. Thus, with a limited effort, we obtain a usable implementation ....

L. Byrd. Understanding the Control Flow of Prolog Programs. In Proc. of the Workshop on Logic Programming, Debrecen, 1980.

....to a goal. It is the depth of the goal in the proof tree, namely the number of its ancestor goals 1. ffl Event type or port (port) attached to an event. The different Mercury event types are as follows. We distinguish between external events which are the traditional ports introduced by Byrd [1], and the internal events which refers to what is occurring inside a procedure. External events call a new procedure is invoked exit the current procedure succeeds fail the current procedure fails redo another solution for the current procedure is asked for on backtracking, and a ....

....is in the else branch of an if then else, which is in the third conjunction of the current goal. 2.3 An example of Mercury event The event structure is illustrated by Figure 1. The displayed structure is related to an event of the execution of the qsort program which sorts the list of integers [3, 1, 2] using a quick sort algorithm. The full code of qsort.m is given in Appendix A. The information contained in that structure indicates that procedure qsort:partition 4 0 is currently invoked, it is the 10 th trace events being generated, the 6 th goal being invoked, and it has 4 th ancestors ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, Debrecen, Hungary, 1980.

....can be used both to experiment various trace models and to validate the different event specifications. We have hence a formal framework to specify and prototype trace models. 1 Introduction The basic model for tracing Prolog executions is Byrd s box model, described in a rather informal way in [4]. As detailed in [19] Prolog debugging systems have quite different interpretations of what Byrd s box model is. It is not always clear whether theses differences come from a misinterpretation of the original model or from a will to improve it. In this article we propose a formal specification of ....

....we insert a redo event just after its success continuation. If the goal fails, its failure continuation will be executed; hence we insert a fail event just before it. Equation 7 specifies how to translate the cut. Since the way the cut should be traced is not described in Byrd s original article [4], we handle it the same way as any other atomic goal and we instrument equation 7 in the same manner as 6 equation 6. p : q, r. r : a, b. q : s. s. q : t. a. Figure 3: A Prolog program [ call q) call s) exit s) exit q) call r) call a) exit a) call b) fail b) redo a) ....

[Article contains additional citation context not shown here]

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, Debrecen, Hungary, 1980. 10

....a tuple of event attributes. An event attribute is an elementary piece of information that can be extracted from the current state of any particular point of the program execution. A trace can be seen as tuples of a database ordered by time. The Mercury trace is an adaptation of Byrd s box model [4]. The attributes of the Mercury trace are: the event number, the call number, the execution depth, the port, the determinism, the procedure (defined by a module name, a name, an arity and a mode number) the live arguments, the live non arguments variables, the goal path and the ancestor stack. A ....

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, Debrecen, Hungary, 1980.

....of PROLOG programs. We present a precise mathematical specification of the box model for definite programs as it was informally introduced by Byrd. We also give a sketch of how to generalize this specification to normal logic programs. 1 Introduction The box model as introduced by Byrd (cf. [1, 2]) describes the process of finding an answer to a query wrt a logic program by means of a chronological trace protocol. This protocol contains entries for primitive events associated with the execution of PROLOG procedures. Basic events are call (a procedure is being entered) exit (a procedure ....

Byrd, L.: Understanding the Control flow of Prolog Programs. In: Proceedings of the Logic Programming Workshop, Debrecen, pages 127--138, 1980.

....The canonical step types for the forward chaining interpreter we have used are: working memory assertions . rule instantiation creations . conflict resolution strategy applications . rule instantiation firings The canonical step type we use for the backward chaining interpreter is the Byrd Box (Byrd 1980) model inference steps call, redo, exit, and fail. As stated above there are two ways to meter the canonical steps, by summing their number and by measuring the time taken for the steps to execute. The advantage of counting the steps is that the metric directly maps onto the program behaviour, ....

Byrd, L. Understanding the Control Flow of Prolog Programs. In S-A Tarnlund (ED.), Proceedings of the 1980 Logic Programming Workshop, pp. 127-138, 1980.

....The meta interpreter creates a description file of the tree. The graph description language used is GML (Graph Modeling Language) The procedures of creation of node and edge generate GML data. Box oriented trace A box oriented trace gives a sequence of events inspired by those proposed in [3]. The meta interpreter is instrumented following the tracing methods of Prolog programs described in [14, 18] The trace format that we chose contains eight ports including four for the non admissible sub goals. These ports are call, fail, exit, redo, call na, fail na, exit na, redo na. The na ....

L. Byrd. Understanding the control flow of Prolog programs. In S.-A. Tarnlund, editor, Logic Programming Workshop, Debrecen, Hungary, 1980.

....PV systems available. As a guide to the following discussion, figures 6 to 9 show the last state representations of the four PV systems when tracing a simple example program (figure 5) The Spy tracer is a stepwise, linear, textual PV system which adopts the Byrd Box model of Prolog execution (Byrd, 1980). The model uses a procedural interpretation of Horn clause logic. The head of a clause is classed as a procedure and the tail treated as one or more sub procedures. Each procedure or sub procedure can have one of four states: call, exit, fail or redo. On invocation the procedure is classed as a ....

Byrd, L. (1980). Understanding the control flow of Prolog programs. In S-A Tarnlund (Ed.), Proceedings of the Logic Programming Workshop, Debrecen, Hungary.

....A similar visualizer was used within the KEATS project [Domingue, 1989; Eisenstadt, 1990] to visualize the backward chaining production system. The players in the visualization are the instantiated Prolog predicates or goals in the proof tree. The events, which are adapted from the Byrd Box Model [Byrd, 1980], are: call (trying to prove a goal) exit (a goal succeeding) fail 1st (a goal failing the first time attempted) fail nth (a goal having succeeded earlier, later failing on backtracking) and redo (re attempting to satisfy a goal) There is a corresponding state and mapping for each event type ....

Byrd, L. (1980) Understanding the Control Flow of Prolog Programs. In Proceedings of The 1980 Logic Programming Workshop, pp. 127-138.

....Imperative Procedure Functional Function CSP Process Logic Predicate Object oriented Method Table 2. Explicit control transfer in different paradigms. Paradigm Transfer mode Imperative Procedure call Functional Eager fi reduction Logic Predicate invocation through its call port (c.f. Byrd model [2]) control transfer from one paradigm to the other. The subclasses are coded using the features and caveats of the parent class; this ensures that unexpected interactions will not occur. We will attempt to clarify this statement by four examples: Non Preemptive Von Neumann Target Architecture The ....

Byrd L (1980) Understanding the control flow of Prolog programs. In Logic Programming Workshop, Debrecen.

....age(anna,5) 5 12 7.3.1 Prolog tracing One way of explaining how a Prolog program computed a result is to take the procedural view of logic programs, adopt an execution model of the language, and then show traces of programs. 177 One view of Prolog execution is the box model proposed by Byrd [34], and subsequently described in many sources including [38] In this model, a rule or program is thought of as being enclosed inside a box. There are four ports to the box: call, exit, redo, and fail. Calling is an initial invocation of the Prolog procedure. Exit is used when there is a successful ....

L. Byrd. Understanding the Control Flow of Prolog Programs. In Proceedings of the Logic Programming Workshop, July 1980, pp. 127--138.

.... Mulholland Knowledge Media Institute, The Open University Abstract: The difficulties students have in learning and using Prolog are well documented (e.g. Taylor, 1988) Many of these difficulties are due to the complexity of the execution model (Fung et al., 1990) Ever since the Byrd Box model (Byrd, 1980), the challenge has been to present the execution model in the most effective way. The term Software Visualization has been coined to describe the process of using textual and or graphical formalisms to describe the execution of computer programs. Software Visualizations for Prolog have been ....

....Program Visualization Laboratory (PPVL) Mulholland, 1995) This provided an experimental laboratory allowing a number of fully implemented SVs to be compared within the same environment. PPVL provides similar interface and navigation for each SV and records all user activity at the terminal. Spy (Byrd, 1980) (figure 1, top left) is a stepwise, linear, textual SV system which adopts the Byrd Box model of Prolog execution. Spy gives a basic procedural account of the execution. The head of a clause can be thought of as a procedure and the tail treated as one or more sub procedures. Byrd s aim in the ....

[Article contains additional citation context not shown here]

Byrd, L. (1980). Understanding the control flow of Prolog programs. In S. Tarnlund (Ed.), Proceedings of the Logic Programming Workshop, Debrecen, Hungary.

....S. If the interpreter is in state B, the user can type ; to request a new solution, or . to return the interpreter to state S. This protocol view of Prolog execution is consistent with the usual models of the operational semantics of Prolog. In fact, it is consistent with the Byrd box model[3]. We can design a foreign language interface using this model. We use a function named Try to initiate a query from the foreign language. To simplify matters, and since Prolog implementations always include parsers, we assume that the argument to Try is a string. Using C as the programming ....

Byrd, L. "Understanding the Control Flow of Prolog Programs" In Logic Programming Workshop `80, pp. 127-138. Debrecen, Hungary, 1980.

....The subgoals which have to be satisfied (in this case car and gold or bike and silver) in order for the goal in the head of the rule to be true form the body of the rule. The Spy tracer (see figure 2) is a stepwise, linear, textual SV system which adopts the Byrd Box model of Prolog execution (Byrd, 1980). The model uses a procedural interpretation of Horn clause logic. The head of a rule is classed as a procedure and the body treated as one or more sub procedures. Byrd s aim in the development of Spy was to provide a basic but complete account of Prolog underpinned by a consistent execution ....

Byrd, L. (1980). Understanding the control flow of Prolog programs. In S.

....where the nodes represent goals which are instantiated Prolog predicates, and the arcs represent conjunctions or disjunctions of subgoals. The players in the visualization are the instantiated Prolog predicates or goals in the proof tree. The events, which are adapted from the Byrd Box Model (Byrd, 1980), are: call (trying to prove a goal) exit (a goal succeeding) fail 1st (a goal failing the first time attempted) fail nth (a goal having succeeded earlier, later failing on backtracking) and redo (re attempting to satisfy a goal) There is a corresponding state and mapping for each event type ....

Byrd, L. (1980). Understanding the Control Flow of Prolog Programs. In S. A. Tarnlund (Ed.), The 1980 Logic Programming Workshop, (pp. 127-138).

....and many claims made regarding their usefulness and suitability for various potential user populations. This paper will consider the suitability of four such debuggers for neophyte Prolog programmers. We shall present an analysis of an empirical investigation into the relative benefits of: a) Spy (Byrd, 1980), b) Prolog Trace Package (PTP) Eisenstadt, 1984) c) Transparent Prolog Machine (TPM) Eisenstadt and Brayshaw, 1988; Brayshaw and Eisenstadt, 1991) and d) the Textual Tree Tracer (TTT) Taylor, du Boulay and Patel, 1992) Specifically the analysis will attempt to go further than a simple ....

....Macintosh TM system 7.1. PPVL provides common interface and navigation for all tracers so differences in performance due to the ease of use of different interface technologies are minimised. PPVL also internally records all user activity at the terminal. Spy uses the Byrd Box model of execution (Byrd, 1980) which uses four status codes: call, exit, fail and redo. PTP uses a range of symbols to differentiate clause and goal and also highlights six types of failure. Spy and PTP are both textual and develop linearly down the screen. They also both use numbers preceded by an underscore to denote ....

Byrd, L. (1980). Understanding the control flow of Prolog programs.

....and that in many instances, more complex schemes have little advantage over simpler ones. Keywords: visualization of Prolog (program) execution, unification 1 Introduction The same features that give Prolog its powerful semantics also make it difficult to learn and debug. The common 4 port model [Byrd80] is of limited assistance since it does not correspond to Prolog s declarative execution model. Furthermore, the 4 port debugger typically provides information in low bandwidth textual form. This results in confusion, dissatisfaction, and inefficiency for users, especially novices. A tree is a ....

L. Byrd, "Understanding the Control Flow of PROLOG Programs", Proceedings of the Logic Programming Workshop, edited by S.- A. Tarnlund, pp. 127--138, 1980.

....automating explicit undo facilities for programming languages (Archer et al. 1984; Leeman, 1986; Teitelman, 1978; Vitter, 1984) are also relevant to replay debugging. Some Prolog debuggers use the language s built in backtracking model to support limited reverse execution (Bowen et al. 1984; Byrd, 1980). Ordinary debuggers typically conflate the notion of an event site with that of an event execution, sometimes relying on a repetition count to indicate which execution is wanted (e.g. stop on the fifth repetition of the call at line 17 ) Identifying events via simple integer time values has ....

Byrd, L. (1980). Understanding the control flow of prolog programs. In Proc. Logic Programming Workshop, Debrecen, Hungary, pages 127--138. Also Univ. of Edinburgh Dept. of Artificial Intelligence Research Paper 151.

....is often crucial that the programmer obtain a clear view of the program state (including, if possible, the program point) from the picture displayed. In this application visualization is clearly complementary to other methods such as assertions [AM94, DNTM89, BDD 97] or text based debugging [Byr80, Duc92, Fer94] In fact, many proposed visualizations designed for debugging purposes can be seen as a graphical front end to text based debuggers [DN94] This work has been partially supported by ESPRIT LTR project DISCIPL # 22532 and CICYT Projects E96 1015 265 and TIC96 1012 C02 01. We wish ....

L. Byrd. Understanding the Control Flow of Prolog Programs. In S.-A. Tarnlund, editor, Workshop on Logic Programming, Debrecen, 1980.

No context found.

L. Byrd. Understanding the control flow of prolog programs. In S.-A. Tarnlund, editor, Proceedings of the Workshop on Logic Programming, 1980.

No context found.

3 L. Byrd. Understanding the control flow of prolog programs. In S.-A. Tarnlund, editor, Proc. of the Workshop on Logic Programming, Debrecen, 1980.

No context found.

Lawrence Byrd. Understanding the control flow of Prolog programs. In Proceedings of the 1980 Logic Programming Workshop, pages 127--138, Debrecen, Hungary, July 1980.

No context found.

Byrd, L., "Understanding the Control flow of Prolog programs," In Tarnlund, S (Ed), Proceeding of the Logic Programming Workshop, 1980, pp 127-138.

No context found.

L. Byrd. Understanding the control flow of Prolog programs. In Logic Programming Workshop, Debrecen, 1980.

Online articles have much greater impact   More about CiteSeer.IST   Add search form to your site   Submit documents   Feedback  

CiteSeer.IST - Copyright Penn State and NEC