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

Download Presentation
Download Policy: The content available on the website is offered to you 'AS IS' for your personal information and use only. It cannot be commercialized, licensed, or distributed on other websites without prior consent from the author. To download a presentation, simply click this link. If you encounter any difficulties during the download process, it's possible that the publisher has removed the file from their server.

Recommend


More recommend