We define a small step operational semantics for a core of Haskell. We modify this semantics to generate traces, specifically Augmented Redex Trails. This small and direct definition of Augmented Redex Trails shall improve our understanding of them and shall help to extend them systematically

Chitil, Olaf

English

Kent Academic Repository

A Semantics for Tracing— Work in Progress —Olaf Chitil?University of York, UKolaf@cs.york.ac.ukAbstract. We define a small step operational semantics for a core ofHaskell. We modify this semantics to generate traces, specifically Aug-mented Redex Trails. This small and direct definition of AugmentedRedex Trails shall improve our understanding of them and shall help toextend them systematically.1 Hat — The Haskell TracerHat is a tool for viewing the computation of a Haskell program in various ways.Hat enables the programmer to understand how the various parts of a programcause the computation to perform the observed actions. It is useful for debugging,program comprehension and teaching [3].Hat transforms a Haskell program into a new Haskell program. When thecompiled new program is executed, it writes a trace to a file in addition to anynormal I/O the original program would perform. Hat includes several separatetools for viewing the trace in various ways.2 AimsHat’s trace, called Augmented Redex Trail (ART), is a complex directed graph.The only formal definition of an ART is given through the transformation thatenables its creation. However, this definition is inadequate. To obtain an ARTof a program’s computation, the program has to be transformed and then beexecuted to create the trail. This has the following disadvantages:– It is hard to determine the ART of even a simple computation by hand.– The second stage of obtaining an ART is based on the semantics of thetransformed program. This is rather confusing, because the purpose of anART is to give an abstract view of the computation of the original program.? The work reported in this paper was supported by the Engineering and PhysicalSciences Research Council of the United Kingdom under grant number GR/M81953.– Although it is the purpose of an ART to give an abstract view of a computa-tion, a description of the computation of a program is not part of the defini-tion. It remains unclear which assumptions about the operational semanticsare made, both in that an ART shall be an abstraction of a computationand that the execution of the transformed program shall yield the desiredART.So the transformation defines an ART only in a very indirect manner, asdepicted here:computation semantics←− program 1 transformation−→ program 2 semantics−→ ARTWe conclude that the transformation is a good definition of an implementa-tion of generating ARTs but not a good definition of ARTs themselves.Hence we are working on a direct definition of ARTS. Because an ART shallgive an abstract view of a computation, we start with a high-level semantics ofa functional language and then modify it to describe ARTs beside the normalsemantics. This semantics will not have the disadvantage listed before and wecan furthermore use it for the following purposes:– Inconsistencies between the two definitions of ARTs will improve our under-standing of them. The final consistency of the two definitions of ARTs willgive us confidence that we have defined what we had in mind.– To prove the correctness of the transformation that implements ART gener-ation.– To extend ARTs systematically to language constructs for which they arenot yet (properly) defined, for example list comprehensions and IO.– In [2] it is claimed that the Redex Trail of a program is complete, that“every reduction occurring in the computation can be observed in the trail”.It would be nice to prove this and similar properties.3 Design DecisionsAn ART is a graph that describes the reductions of a computation and theirrelationships. Hence our basis has to be an operational semantics.We have to use a call-by-need semantics — a call-by-name semantics is notsufficient — because an ART describes how expressions are shared. Especially,it is visible in an ART that when a shared expression is evaluated, it is replacedby the result at all its usage points.We do not want to tie ourselves to a specific abstract machine. Hence Launch-bury’s big-step semantics for call-by-need [1] is an obvious starting point.A big-step semantics only describes computations of expressions that havea value, that is, a weak head normal form. However, we are also interested inobtaining an ART for expressions that have value ⊥, that is, whose evaluation2leads to an error, a black hole, or an infinite computation that has to be inter-rupted. To be able to obtain a computation in this case, we switch to a smallstep variant of Launchbury’s semantics.An ART is basically independent of the order in which the reductions ofa computation are performed.1 An ART for a terminating eager and a lazycomputation of the same program may differ only in so far that the eager com-putation evaluates all arguments completely, whereas the lazy computation mayleave some partially unevaluated. To clearly express this property of ARTs weseparate our operational semantics into a definition of non-deterministic rewrit-ing steps and an arbitrary function that chooses the next rewriting step. Thisevaluation strategy function may implement eager, lazy or any other evaluationorder.4 An Operational SemanticsThe syntax is defined in Figure 1. We give a semantics to an expression bydefining to which value it evaluates.To express sharing the semantics operates on rooted graphs instead of ex-pressions. An expression is respresented by a rooted graph, that is, a graph plusa graph node or pointer which indicates the top of the expression. A graph,denoted by Γ or ∆, is a partial mapping from nodes to expressions. We writeit as a set of tuples p 7→ M . The nodes of the graph are its domain, that is,the domain of the mapping. The operator comma (,) extends a graph by a nodeunder the assumption that the node does not occur in the domain of the graph.Computation is performed only on closed graphs, that is, graphs where the nodesof all terms in the graph are a subset of the domain of the graph. So a closedgraph represents a closed term with shared subterms.The value lookup function defined in Figure 2 just follow chains of pointers(graph nodes). The function is undefined, if the expression points to a cycle ofpointers.In Figure 3 we define a reduction relation on graphs, where Γ ⇒ ∆ meansthat the graph Γ reduces to the graph ∆. A computation is a finite or infinitesequence of graphs Γ1, Γ2, . . . with Γi ⇒ Γi+1 for all graphs in the sequence.The reduction relation is non-deterministic. We do not discuss the evaluationstrategy here.The computation of an expression M is the computation beginning with thegraph {p 7→ M}. M evaluates to a value, if its computation is finite with thelast graph ∆ having the property ∆(p) = V .The sharing rules assure that a redex will never be a proper subexpressionof a node expression, but that every redex will be a node expression. On theone hand this simplifies the other rules; we do not require an evaluation context.However, most importantly we will need this property later when we modify thesemantics for defining ARTs.1 We can easily extend ARTs to record the order of reductions. However, for mostpurposes it is best to ignore this order.3variable x, y, zgraph node (pointer) p, q, rexpression M,N := x variable| p node| λx.M abstraction| M N application| C data constructor| case M of {Ci xi 7→ Ni}ki=1 data destruction| let {xi = Mi}ki=1 in N local definitionvalue V := λx.M abstraction| C p1 . . . pn with n ≥ 0 (part.) applied constructorFig. 1. Syntax〈M〉Γ ={M , if M is not a graph node〈Γ (p)〉Γ , if M = p and p ∈ dom(Γ )Fig. 2. Value Lookup Function〈M〉Γ = λx.NΓ, p 7→M q ⇒ Γ, p 7→ N [q/x] application reduction〈M〉Γ = Cj qΓ, p 7→ case M of {Ci xi 7→ Ni}ki=1 ⇒ Γ, p 7→ Nj [q/xj ]case reductionΓ, p 7→ let {xi = Mi}ki=1 in N ⇒ Γ, p 7→ N [q/x], q 7→M [q/x] let reductionSharing rules:Γ, p 7→M N ⇒ Γ, p 7→M q, q 7→ NΓ, p 7→M N ⇒ Γ, p 7→ q N, q 7→MΓ, p 7→ case M of {Ci xi 7→ Ni}ki=1 ⇒ Γ, p 7→ case q of {Ci xi 7→ Ni}ki=1, q 7→MFig. 3. Small Step Reduction RulesNote that there is no reduction inside a variable binding expression. Hencewe also never break up a variable binding expression into several nodes. So wecan instantiate a bound variable by standard substitution.4〈M〉Γ =M , if M is not a graph node〈r〉Γ , if M = p and Γ (p) = srN and r 6= 〈Γ (p)〉Γ , otherwiseFig. 4. Value Lookup Function for ARTs〈M〉Γ = λx.NΓ, p 7→s M q ⇒ Γ, p 7→sr M q, r 7→p N [q/x]application reduction〈M〉Γ = Cj qΓ, p 7→s case M of {Ci xi 7→ Ni}ki=1⇒ Γ, p 7→sr case M of {Ci xi 7→ Ni}ki=1, r 7→p Nj [q/xj ]case reductionΓ, p 7→s let {xi = Mi}ki=1 in N⇒ Γ, p 7→sr let {xi = Mi}ki=1 in N, r 7→s N [q/x], q 7→p M [q/x]let reductionSharing rules:Γ, p 7→sr M N ⇒ Γ, p 7→sr M q, q 7→s NΓ, p 7→sr M N ⇒ Γ, p 7→sr q N, q 7→s MΓ, p 7→sr case M of {Ci xi 7→ Ni}ki=1 ⇒ Γ, p 7→sr case q of {Ci xi 7→ Ni}ki=1, q 7→s MFig. 5. Small Step Reduction Rules for Defining ARTs5 An Operational Semantics Defining ARTsAn ART shall describe a complete computation. However, the reduction rulesupdate expressions in the graph and thus information is lost. To preserve theinformation we do not update any expression but allocate a new graph nodefor a reduction result. We extend each graph node by a pointer pointing to thereduction result of the graph node, if any. Hence we also introduce the nullpointer  for graph nodes that do not have a result. This is the case if theexpression of the node is a value or has not (yet) been reduced.Furthermore, each node has a second pointer to its parent, that is, the nodewhose reduction caused the creation of the node.We write p 7→sr M for a node p with expression M , parent s and resultr. Figure 5 gives the modified semantics that defines ARTs. The value lookupfunction has to be modified to follow result pointers, see Figure 4.56 ConclusionsThe definition does not yet cover all aspects of ARTs and much remains to bedone.References1. John Launchbury. A natural semantics for lazy evaluation. In Conference Recordof the Twentieth Annual ACM SIGPLAN-SIGACT Symposium on Principles ofProgramming Languages, pages 144–154. ACM Press, 1993.2. Jan Sparud and Colin Runciman. Complete and partial redex trails of functionalcomputations. In C. Clack, K. Hammond, and T. Davie, editors, Selected papersfrom 9th Intl. Workshop on the Implementation of Functional Languages (IFL’97),pages 160–177. Springer LNCS Vol. 1467, September 1997.3. Malcolm Wallace, Olaf Chitil, Thorsten Brehm, and Colin Runciman. Multiple-view tracing for Haskell: a new Hat. In Preliminary Proceedings of the 2001 ACMSIGPLAN Haskell Workshop, UU-CS-2001-23. Universiteit Utrecht, 2001.6

A Semantics for Tracing

Abstract

Similar works

Full text

Available Versions

Kent Academic Repository