Computationally Equivalent Elimination of Conditions

1. Computationally Equivalent Elimination of Conditions Traian Florin Şerbănuţă Grigore Roşu University of Illinois at Urbana-Champaign

2. Would it be possible to automatically transform a conditional rewrite system 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 arenatural and useful • 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 handlecontrol contexts

3. Overview • Why conditional rules are inconvenient • Computational equivalence • Previous transformations • Proposed solution • Optimizations & extensions • Conclusion and future work

4. -> * θ(cl) -> cr θ(l) θ(r) Conditional Rules • We here consider normal conditional rules:- one equality in condition, oriented • condition’s rhs cris a normal form constant • all variables in the rule occur in l • (technique not limited to these) l->r  cl->cr To apply the rule, one should first recursively show

5. ? control context -> … ? -> θ(cl) θ(l) Many rules may apply at the same time Bookkeeping, search, backtracking; complex engines Why Conditional Rules are Inconvenient l->r  cl->cr t

6. “Bad” Example Signature Peano natural numbers plus … odd, even : Nat -> Bool Rules 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 even(21). Neither finished even(31) in less than 2h.

7. Many 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 the following trace of function calls: f Envf g h f x

8. TRSR’ φ φ(t) R’ R ψ nfR’(φ(t)) nfR(t) Computational Equivalence CTRS R t R’ can be used transparently to perform computations in R Extract the normal form of t in the original system Get a normal form of the transformed term in R’ Create a better world for t – send it to R’ We would like a normal form of t in R

9. Previous Transformations … not computationally equivalent, or impose strong restrictions on the original CTRS, or require strong reduction support from target TRS

10. Running Example: Bubble-sort One-rule CTRS (can be quite efficient on parallel engines – linear time): .(x, .(y,l))-> .(y, .(x,l) x>y->true

11. Previous Transformations: Unravelings • Bergstra&Klop, Marchiori, Ohlebusch, … .(x, .(y,l))->.(y, .(x,l) x>y->true goes to: • Modular, reflect termination • Useful for analyzing CTRSes • Not Computationally Equivalent .(2, .(3, .(1,[]))) -> U(2>3,2,3,.(1,[])) -> U(false,2,3,.(1,[])) .(x, .(y,l) -> U(x>y,x,y,l)U(true,x,y,l) -> .(y, .(x,l))

12. Ci represents the current status of the i-th conditional rule that can be potentially applied on  C1,C2,C3,…,Cn Previous Transformations: Viry (I) • Fore each operation in the term, store the status of the conditions in all rules applicable at that position • Not Unravelling (loses modularity) • First step toward computational equivalence 

13. 2 2>3 1 .(3,[]) Previous Transformations: Viry (II) • Viry proves his transformation • preservesreachability,termination, groundconfluence (some strategies needed – conditional eagerness) • … thus, Computational Equivalence • However… .(x,.(y,l)->.(y,.(x.l) if x>y->true … therefore, Viry did not solve the problem, despite the special reduction strategies he requires for the TRS … 2 2>3 Normal form in TRS does not yield normal form in CTRS; … problematic proofs 3 . (1,[])

14. Previous Transformations:“Fix” by Antoy, Brassel and Hanus Restrict CTRS to constructor based and left linear Functional languages are constructor based !!! Bubble sort not constructor-based; so excluded !!! Canonical CTRS-es are also “functional” • Rewriting as a programming paradigm Challenge remains: • Can we transform any CTRS into a computationally equivalent, unrestricted (wrt evaluation) TRS ?

15. 1 2 1 2 0 2 3 1 1 1 1,[] 3,[] 3,[] Previous Transformations: Rosu • Bits telling whether conditions can be tried • “Flush” condition bits when needed • No left linearity nor constructor baseness needed • Requires evaluation strategies for the TRS • if_then_else_fi and equal?(_,_) 0 1 0 1 0 1

16. Our Solution in This Paper • Add Rosu’s “flushing” to Viry’s transformation • Transform the i-th conditional rule topped in σ into • And add rules for “flushing” the conditions l -> r cl -> cr (l,,i) -> (l,{(cl)},i) (l,{(cr)},i) -> {(r)} σ(…,{ti},…,c1,…,ck) -> {σ(…,ti,…,,…,)} {{x}} -> {x}

17. 1 2 false 1 2 1 3,[] 3,[] 3,[] Example – Bubble Sort .(x, .(y,l))->.(y, .(x,l) x>y->true gets translated to: .(x,.(y,l,b),) -> .(x,.(y,l,b),x>y) .(x,.(y,l,b),true) -> {.(y,.(x,l,),)} .(x,{l},b) -> {.(x,l,)} {{l}} -> {l} 2>3 false 2 1>2 false 2>1 true 3 3>1 true 2>3 false 1,[]

18. Analogy to CPS Transformation • 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, statingthe status of the conditional rules

19. Our Results • Computational Equivalence • canonical CTRS canonical TRS on relevant terms • Reachability reflected under left-linearityorconfluence of the CTRS • Under left-linearity • confluence yields confluence • termination yields termination • Termination, confluence, left-linearity reflected

20. Optimizations • Condition Sharing • Compact rules sharing same lhs and cond. lhs • Non-overlapping rules with same top op. • Share the same additional position • Constructor-based systems • The “flushing” brackets no longer necessary

21. Optimized Odd/Even 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 is transformed to (optimizations included) odd(s n,) -> odd(s n,even(n,,)) odd(s n,true) -> true odd(s n,false) -> false odd(0, b) -> false Similarly for even Becomes linear due to “condition sharing”

22. Experimental results (I)

23. Experimental Results (II) Quotient / Remainder Simple PL with arrays – permutation generation

24. Extensions: Matching in conditions • Matching in conditions powerful and useful; for example, “big-step” SOS rules can be seamlessly expressed: <E1+E2,S> -> <V1+V2,S2> if <E1,S> -> <V1,S1> & <E2,S1> -> <V2,S2> encodes the SOS rule <E1,S> -> <V1,S1> , <E2,S1> -> <V2,S2> <E1+E2,S> -> <V1+V2,S2> • Our transformation and results extend easily (but tediously) to CTRS-es with matching in conditions • For example, our transformation produces: <E1+E2,S,> -> <E1+E2,S,c1(<E1,S,>)> <E1+E2,S,c1(<V1,S1,>)> -> E1+E2,S,c2(<E2,S1,>,V1)> <E1+E2,S,c2(<V2,S2,>,V1)> -> <V1+V2,S2,>

25. Extensions: Rewriting Modulo Equations? • Our results work only for restrictedrewriting modulo assoc, comm, unit • when for any conditional rule, at most one matching at any position at any time • General problem open … • Appears hard

26. Conclusion and Future Work • Previous CTRS-to-TRS translations aiming at computational equivalence • have flaws or • impose strong restrictions on CTRS, or • require special support from the TRS • We proposed a general & automatic transformation avoiding most limitations of previous transformations • Future work • Extension to non-deterministic CTRSes (rewriting logic) • Implementation & Debugging / Tracing • Can rewriting modulo be supported as well? • Optimize “condition flushing” • Investigate analysis capabilities of the transformation

27. Additional slides

28. Simulating join systems by normal ones l -> r <= cl1=cr1,cl2=cr2,…,cln=crn • Most people write conditional rules this way: • With some additional helping operations • One gets the following normal rule Signature eq? : s s -> Bool __ : Bool Bool -> Bool (trivial) Equations eq?(x,x) = true l -> r <= eq?(cl1,cr1) … eq?(cln,crn ) -> true

29. 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(false,x,y) = y

30. Many 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 the following trace of function calls: f Envf g h f x

31. Towards a Rewriting Virtual Machine 1mai punem asta? • The proposed transformation can be applied as a front-end to any 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

32. 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

33. Previous TransformationsViry (II) • For each , number all conditional rules where l = (t1,…,tn), from 1 to k • Add k additional arguments to  l -> r cl -> cr

34. Previous TransformationsViry (III) ρσ,i: l -> r cl -> cr • Transform the i-th such rule ρσ,i where l = (t1,…,tn), into two rules (u) adds  for extra arguments (l,X,i) adds distinct variables for extra arguments, except the i-th at root, which is X (l,,i) -> (l,[(cl),Vars(l)],i) (l,[(cr),Vars(l)],i) -> (r)

35. 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, statingthe status of the conditional rules