declarative programming with function patterns
play

Declarative Programming with Function Patterns Michael Hanus - PowerPoint PPT Presentation

LOPSTR 2005 Declarative Programming with Function Patterns Michael Hanus Christian-Albrechts-Universit at Kiel (joint work with Sergio Antoy, Portland State University) F UNCTIONAL L OGIC L ANGUAGES Approach to amalgamate ideas of


  1. LOPSTR 2005 Declarative Programming with Function Patterns Michael Hanus Christian-Albrechts-Universit¨ at Kiel (joint work with Sergio Antoy, Portland State University)

  2. F UNCTIONAL L OGIC L ANGUAGES Approach to amalgamate ideas of declarative programming • efficient execution principles of functional languages (determinism, laziness) • flexibility of logic languages (constraints, built-in search) • avoid non-declarative features of Prolog (arithmetic, I/O, cut) • combine best of both worlds in a single model (higher-order functions, declarative I/O, concurrent constraints) • Advantages: ➜ optimal evaluation strategies [JACM’00,ALP’97] ➜ new design patterns [FLOPS’02] ➜ better abstractions for application programming (GUI programming [PADL ’00], web programming [PADL ’01]) CAU Kiel Michael Hanus 2

  3. F UNCTIONAL L OGIC P ROGRAMS : C URRY [POPL’97] CAU Kiel Michael Hanus 3

  4. F UNCTIONAL L OGIC P ROGRAMS : C URRY [POPL’97] Datatypes ( ≈ admissible values): enumerate all data constructors ☛ ✟ data Bool = True | False data List a = [] | a : List a -- [a] ✡ ✠ CAU Kiel Michael Hanus 3

  5. F UNCTIONAL L OGIC P ROGRAMS : C URRY [POPL’97] Datatypes ( ≈ admissible values): enumerate all data constructors ☛ ✟ data Bool = True | False data List a = [] | a : List a -- [a] ✡ ✠ Functions : operations on values defined by equations (or rules) f t 1 . . . t n | c = r defined condition patterns expression operation (optional) Pattern: linear data term ✓ ✏ (++) :: [a] -> [a] -> [a] head :: [a] -> a [] ++ ys = ys head (x:xs) = x (x:xs) ++ ys = x : xs ++ ys ✒ ✑ CAU Kiel Michael Hanus 3

  6. F UNCTIONAL L OGIC P ROGRAMS Functional evaluation: (lazy) rewriting → → → [1,2]++[3] 1:([2]++[3]) 1:(2:([]++[3])) [1,2,3] Functional logic evaluation: equation solving, guess values for unknowns { xs �→ [1,2], x �→ 3 } xs++[x] =:= [1,2,3] ❀ CAU Kiel Michael Hanus 4

  7. F UNCTIONAL L OGIC P ROGRAMS Functional evaluation: (lazy) rewriting → → → [1,2]++[3] 1:([2]++[3]) 1:(2:([]++[3])) [1,2,3] Functional logic evaluation: equation solving, guess values for unknowns { xs �→ [1,2], x �→ 3 } xs++[x] =:= [1,2,3] ❀ Define functions by conditional equations : ☛ ✟ last :: [a] -> a last xs | ys ++ [x] =:= xs = x where x,ys free ✡ ✠ last [1,2] 2 ❀ CAU Kiel Michael Hanus 4

  8. M EANING OF “ =:= ” Modern functional logic languages (Curry, Toy): non-strict semantics ➜ lazy evaluation ➜ computing with infi nite structures ➜ comparison of arbitrary infi nite objects? CAU Kiel Michael Hanus 5

  9. M EANING OF “ =:= ” Modern functional logic languages (Curry, Toy): non-strict semantics ➜ lazy evaluation ➜ computing with infi nite structures ➜ comparison of arbitrary infi nite objects? Strict equality (K-LEAF [Giovannetti et al. ’91]) ➜ identity on fi nite data terms ( ❀ not reflexive) ➜ e 1 =:= e 2 satisfi ed iff e 1 and e 2 reducible to same (unifi able) constructor term ➜ “ x =:= head [] ” does not hold CAU Kiel Michael Hanus 5

  10. M EANING OF “ =:= ” Modern functional logic languages (Curry, Toy): non-strict semantics ➜ lazy evaluation ➜ computing with infi nite structures ➜ comparison of arbitrary infi nite objects? Strict equality (K-LEAF [Giovannetti et al. ’91]) ➜ identity on fi nite data terms ( ❀ not reflexive) ➜ e 1 =:= e 2 satisfi ed iff e 1 and e 2 reducible to same (unifi able) constructor term ➜ “ x =:= head [] ” does not hold Disadvantage: strict equality evaluates more than necessary no result! last [failed,2] ❀ CAU Kiel Michael Hanus 5

  11. S TRICT EQUALITY : M OTIVATION Difficulty: comparison of infinite structures ✎ ☞ ⇒ from x = x : from (x+1) from 0 ❀ 0:1:2:3:4:5:... rtail (x:xs) = rtail xs ✍ ✌ should hold with reflexivity rtail (from 0) =:= rtail (from 5) : CAU Kiel Michael Hanus 6

  12. S TRICT EQUALITY : M OTIVATION Difficulty: comparison of infinite structures ✎ ☞ ⇒ from x = x : from (x+1) from 0 ❀ 0:1:2:3:4:5:... rtail (x:xs) = rtail xs ✍ ✌ should hold with reflexivity rtail (from 0) =:= rtail (from 5) : ✞ ☎ from2 x = x : x+1 : from2 (x+2) ✝ ✆ should hold with reflexivity, generally undecidable from 0 =:= from2 0 : CAU Kiel Michael Hanus 6

  13. S TRICT EQUALITY : M OTIVATION Difficulty: comparison of infinite structures ✎ ☞ ⇒ from x = x : from (x+1) from 0 ❀ 0:1:2:3:4:5:... rtail (x:xs) = rtail xs ✍ ✌ should hold with reflexivity rtail (from 0) =:= rtail (from 5) : ✞ ☎ from2 x = x : x+1 : from2 (x+2) ✝ ✆ should hold with reflexivity, generally undecidable from 0 =:= from2 0 : = ⇒ strict equality is not reflexive no solution head [] =:= head [] ❀ (not specific to FLP , e.g., Haskell, Java,. . . ) CAU Kiel Michael Hanus 6

  14. R ELAXING S TRICT EQUALITY ? Is evaluation always necessary? no solution x =:= head [] ❀ Why not: solve x =:= t by binding x to t (without evaluating t )? CAU Kiel Michael Hanus 7

  15. R ELAXING S TRICT EQUALITY ? Is evaluation always necessary? no solution x =:= head [] ❀ Why not: solve x =:= t by binding x to t (without evaluating t )? Desirable in some cases (e.g., last ), non-intuitive in other cases: ✞ ☎ f x | x =:= from 0 = 99 ✝ ✆ f x 99 ❀ (f x, 99) (99, 99) ❀ no termination (f x, f x) ❀ CAU Kiel Michael Hanus 7

  16. R ELAXING S TRICT EQUALITY ? Is evaluation always necessary? no solution x =:= head [] ❀ Why not: solve x =:= t by binding x to t (without evaluating t )? Desirable in some cases (e.g., last ), non-intuitive in other cases: ✞ ☎ f x | x =:= from 0 = 99 ✝ ✆ f x 99 ❀ (f x, 99) (99, 99) ❀ no termination (f x, f x) ❀ Solution: Distinguish between ➜ logic variables: bind only to fi nite constructor terms ➜ pattern variables: bind to arbitrary (unevaluated) terms ❀ function patterns CAU Kiel Michael Hanus 7

  17. F UNCTION P ATTERNS : S YNTAX Function pattern : pattern containing ➜ variables ➜ constructors ➜ defi ned operation symbols ☛ ✟ last :: [a] -> a last (xs ++ [x]) = x ✡ ✠ Advantages: ➜ concise defi nition ➜ xs and x pattern variables ❀ can be bound to unevaluated expressions ➜ last [failed,2] ❀ 2 (with { xs �→ [failed], x �→ 2 } ) CAU Kiel Michael Hanus 8

  18. F UNCTION P ATTERNS : T RANSFORMATIONAL S EMANTICS ➜ Reuse existing semantics and models of functional logic programs ➜ Transform programs with function patterns into standard programs CAU Kiel Michael Hanus 9

  19. F UNCTION P ATTERNS : T RANSFORMATIONAL S EMANTICS ➜ Reuse existing semantics and models of functional logic programs ➜ Transform programs with function patterns into standard programs Basic idea: rule with function patterns �→ set of rules where each function pattern is replaced by its evaluation to some data term Example: Evaluations of xs++[x] : ∗ xs++[x] [x] ❀ xs �→ [] ∗ xs++[x] [x1,x] ❀ xs �→ [x1] ∗ xs++[x] ❀ xs �→ [x1,x2] [x1,x2,x] . . . ⇒ last (xs ++ [x]) = x abbreviates the set of rules last [x] = x last [x1,x] = x last [x1,x2,x] = x ... CAU Kiel Michael Hanus 9

  20. S EMANTICS OF F UNCTION P ATTERNS Potential problems of this approach: CAU Kiel Michael Hanus 10

  21. S EMANTICS OF F UNCTION P ATTERNS Potential problems of this approach: 1. infinite set of transformed rules ❀ perform transformation at run time CAU Kiel Michael Hanus 10

  22. S EMANTICS OF F UNCTION P ATTERNS Potential problems of this approach: 1. infinite set of transformed rules ❀ perform transformation at run time 2. circular definition, e.g., (xs ++ ys) ++ zs = xs ++ (ys ++ zs) ❀ avoid circular definitions by restriction to stratified programs CAU Kiel Michael Hanus 10

  23. S EMANTICS OF F UNCTION P ATTERNS Potential problems of this approach: 1. infinite set of transformed rules ❀ perform transformation at run time 2. circular definition, e.g., (xs ++ ys) ++ zs = xs ++ (ys ++ zs) ❀ avoid circular definitions by restriction to stratified programs 3. non-left-linear transformed rules idpair x = (x,x) f (idpair x) = 0 Transformation into: f (x,x) = 0 Not allowed in standard FLP ❀ linearization of left-hand sides: f (x,y) | x=:=y = 0 Details ❀ paper CAU Kiel Michael Hanus 10

  24. E XAMPLE : P ROBLEM S OLVING Dutch National Flag (Dijkstra’76): arrange a sequence of objects colored by red, white or blue so that they appear in the order of the Dutch flag CAU Kiel Michael Hanus 11

  25. E XAMPLE : P ROBLEM S OLVING Dutch National Flag (Dijkstra’76): arrange a sequence of objects colored by red, white or blue so that they appear in the order of the Dutch flag data Color = Red | White | Blue CAU Kiel Michael Hanus 11

  26. E XAMPLE : P ROBLEM S OLVING Dutch National Flag (Dijkstra’76): arrange a sequence of objects colored by red, white or blue so that they appear in the order of the Dutch flag data Color = Red | White | Blue solve (x++[White]++y++[ Red ]++z) = solve (x++[ Red ]++y++[White]++z) CAU Kiel Michael Hanus 11

Recommend


More recommend