1 / 20

Towards Eliminating Conditional Rewrite Rules

Towards Eliminating Conditional Rewrite Rules. Grigore Rosu Computer Science Department University of Illinois at Urbana-Champaign.

vicky
Download Presentation

Towards Eliminating Conditional Rewrite Rules

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Towards Eliminating Conditional Rewrite Rules Grigore Rosu Computer Science Department University of Illinois at Urbana-Champaign

  2. Would it be possible to automatically transform each conditional rewrite rule into an unconditional one, so that a straightforward and more amenable to optimize unconditional rewriting engine can be used instead? ? Observations and Motivation • Equational definitions areindispensable • Executableequational specifications desirable • Many languages support them • Typically executed by rewriting • However, many interesting specifications involveconditional equations • Conditional rewritingharder to implementdue to the necessity to hadlecontrol contexts

  3. Overview • Why conditional rules are inconvenient • Analogy with functional languages and with CPS transformations • An unsatisfactory solution • The proposed solution • Towards RVM (rewriting virtual machine) • Conclusion and future work

  4. To apply the rule, one should first recursively show -> * * θ(ui) ->;<- θ(vi) θ(l) θ(r) Conditional Rules • We here consider standard conditional rules: • equalities in conditions are interpreted as “join”, • all variables in the rule occur in l l->r  u1=v1, u2=v2, …, um=vm

  5. ? ? ? ? control context -> -> -> -> θ(l) Why Conditional Rules are Inconvenient l->r  u1=v1, u2=v2, …, um=vm … … … θ(u1) … … t … ? θ(v1) … -> … … … θ(um) … … … θ(vm)

  6. A Bad Conditional Equational Spec Signature Peano natural numbers plus … odd, even : Nat -> Bool Equations odd(s n) = true even(n) = true odd(s n) = false even(n) = false odd(0) = false even(s n) = true odd(n) = true even(s n) = false odd(n) = false even(0) = true On a 2.4GHz 4GB machine, Maude takes 7.9s and Elan 548.1s to evaluate odd(21). Neither finished odd(31) in less than 2h.

  7. Most functional languages today are applied a CPS transformation and then compiled. This way, all function calls occur on tail positions, so nested environments not needed anymore. Thus, the control context is translated into data context. Can we do a similar thing for conditional rewrite rules and transform them into unconditional ones? ! g Envg h f x h f f x x Analogy with Functional Languages Consider evaluating f(…g(…h(…f(x)…)…)…) f Envf g h f x

  8. Axiomatizing Equality (joinability) • There is no way to avoid evaluating the equalities in the conditions of rules • No control context will be created for this purpose, but joinability needs to be explicit Signature equal? : s s -> Bool __ : Bool Bool -> Bool (trivial) Equations equal?(x,x) = true equal?((x1,…,xn),(y1,…,yn)) = equal?(x1,y1)  …  equal?(xn,yn) equal?((x1,…,xn),(y1,…,yn’)) = false

  9. Axiomatizing IF • We will still need to treat differently the cases when the condition is true/false • No control context will be created for this purpose, but IF needs to be explicit Signature if : Bool s s -> s Equations if(true,x,y) = x if(true,x,y) = x

  10. An Unsatisfactory Transformation l -> r u1=v1, u2=v2, …, um=vm • One can transform each conditional equation into an unconditional equation • This transformation preserves reachability, so works fine with the search in Maude • However, it may lead to non-termination of rewriting, so it is not practical l -> if(equal?(u1,v1)  …  equal?(um,vm), r, l)

  11. Bit i is 0 if and only if the i-th conditional rule that can be potentially applied on  has been tried and failed 00110011001101 Idea of the Proposed Solution 1 • Pass control context into data context! • Together with each operation in the term, store the status of the potential applications of rules 

  12. Idea of the Proposed Solution 2 • For each , number all conditional rules where l = (t1,…,tn), from 1 to k • Add k additional (boolean) arguments to  l -> r u1=v1, u2=v2, …, um=vm

  13. Idea of the Proposed Solution 3 l -> r u1=v1, u2=v2, …, um=vm • Transform the i-th such rule where l = (t1,…,tn), into (u) adds true for extra arguments (l,true,i) adds distinct variables for extra arguments, except the i-th at root, which is true (l,true,i) -> if(equal?((u1),(v1))…  equal?((um),(vm), (r), (l,false,i))

  14. An Example Transformation 1 The conditional specification … Signature Peano natural numbers plus … odd, even : Nat -> Bool Equations odd(s n) = true even(n) = true odd(s n) = false even(n) = false odd(0) = false even(s n) = true odd(n) = true even(s n) = false odd(n) = false even(0) = true

  15. An Example Transformation 2 … translates automatically into Signature Peano natural numbers plus … odd, even : Nat Bool Bool -> Bool Equations odd(s n, true, b) = if(equal?(even(n,true,true),true), true, odd(s n, false, b)) odd(s n, b, true) = if(equal?(even(n,true,true),false), false, odd(s n, b, false)) odd(0, b, b’) = false Similarly for even

  16. Analogy to CPS Transformation • Functional programs are typically applied a CPS transformation and then compiled • Simpler and more efficient compilers • CPS transformation adds an additional argument to each function, stating the remaining part of the computation • We do a similar thing, by adding a “tuple” argument to some operations, stating what conditional rules are still left to try

  17. Towards a Rewriting Virtual Machine 1 • The proposed transformation can be applied as a front-end to existing rewriting engines • On the odd/even example, it already brings a 3x speed increase in Maude and 10x in Elan One can develop a basic, unconditional and very fast rewrite virtual machine, and then define higher level languages, like Maude or Elan, by transforming their specs into unconditional ones

  18. Towards a Rewriting Virtual Machine 2 • Such an RVM can also be used to define and design programming languages and analysis tools for them • We have operationally defined as unconditional rewrite systems several (fragments of) languages • BC,Scheme, Java, ML, OCAML • Continuation-based definitions • About 2-3 weeks per language • Actual Scheme is only 50% faster than our unconditional rewrite definition in Maude! • However, an unconditional RVM can be very fast and highly parallel, so one can get quickly correct and competitive interpreters for programming languages

  19. Related Work • Conditional rewrite rules have been translated into unconditional ones for analysis purposes (termination) • Ohlebusch, Middledrop among many others • Known translations tend not to preserve computation, but only termination and/or confluence; designed for analysis not for computation

  20. Conclusion and Future Work • Automatic transformation of conditional rewriting systems (CTRS) into unconditional ones (TRS) • Much work left to do • Extend it to rewriting modulo equations • Allow extra variables and matching in conditions • Rewriting strategies? (curr. works only for innermost) • Investigate analysis techniques for CTRSs based on the presented transformation • Termination and/or confluence

More Related