the rpc calculus
play

The RPC Calculus Symmetrical RPC in an Asymmetrical World Ezra - PowerPoint PPT Presentation

The RPC Calculus Symmetrical RPC in an Asymmetrical World Ezra Cooper Philip Wadler September 8, 2009 Dream of unified web programming Dream of unified web programming What we want Reality of web programming Reality of web programming


  1. The RPC Calculus Symmetrical RPC in an Asymmetrical World Ezra Cooper Philip Wadler September 8, 2009

  2. Dream of unified web programming

  3. Dream of unified web programming What we want

  4. Reality of web programming

  5. Reality of web programming It’s a bit more fiddly.

  6. Reality of web programming It’s a bit more fiddly. Here’s why:

  7. Traditional program

  8. Traditional program

  9. Traditional web program .

  10. Traditional web program .

  11. Unified program

  12. Unified program Simplifies the work of web programming

  13. Unified program Simplifies the work of web programming The Links language: http://groups.inf.ed.ac.uk/links

  14. Dream of a unified language Waking up: ◮ Desire to control location explicitly, with a light touch; ◮ Need control for performance and security reasons; ◮ Tricky because of asymmetrical client/server relationship.

  15. Roadblock: Asymmetrical client/server relationship

  16. Roadblock: Asymmetrical client/server relationship

  17. Stateless server Web applications should not store control state at the server.

  18. Stateless server Web applications should not store control state at the server. Server should encode all state and give it to client.

  19. Stateless server Web applications should not store control state at the server. Server should encode all state and give it to client. For this talk, state = call stack.

  20. Example program fun checkPassword ( name , password ) { # load this user’s row from database & check password var u = lookupUser ( name ); u . password == password } fun validate () { var auth = checkPassword ( fieldValue (”name”) , fieldValue (”password”))); if ( auth ) displaySecretDocument (); else displayErrorMessage (); }

  21. Example located program fun checkPassword ( name , password ) server { # load this user’s row from database & check password var u = lookupUser ( name ); u . password == password } fun validate () client { var auth = checkPassword ( fieldValue (”name”) , fieldValue (”password”))); if ( auth ) displaySecretDocument (); else displayErrorMessage (); }

  22. Example located program: server push fun findFlights ( flightQuery ) server { # Query each vendor for its own matching flights for ( vendor ← airlines ()) { var flights = queryVendor ( vendor , flightQuery ); # Send this vendor’s flights to the browser displayFlights ( flights ); } } fun displayFlights ( flights ) client { # Add each flight to the page for ( flight ← flights ) addToPage ( flight ); }

  23. Example: higher-order functions How should this code behave? fun usernameMap ( f ) server { var users = getUsersFromDatabase (); for ( u ← users ) [ f ( u . name) ] } fun userNameFirstThree () client { usersMap ( fun ( name ) { take (3 , name ) } ); }

  24. Example: higher-order functions How should this code behave? fun usernameMap ( f ) server { var users = getUsersFromDatabase (); for ( u ← users ) [ f ( u . name) ] } fun userNameFirstThree () client { usersMap ( fun ( name ) { take (3 , name ) } ); } ⊲ Functions in lexical client-context execute on client.

  25. What I want to show you ◮ How to compile this language for the asymmetrical client-server model,

  26. What I want to show you ◮ How to compile this language for the asymmetrical client-server model, ◮ How the compilation factors into standard techniques,

  27. What I want to show you ◮ How to compile this language for the asymmetrical client-server model, ◮ How the compilation factors into standard techniques, ◮ How these these techniques can be presented formally and concisely.

  28. How it’s done main f g Client Server Call to f (server) {Call f} Call to g (client) {Call g, k} {Continue r, k} Return r from g {Return s} Return s from f Source language: Implementation: call/return style request/response style

  29. Getting technical

  30. Source language: the located lambda calculus

  31. Source language: the located lambda calculus LM | λ a x . N | λ x . N | x | c L , M , N ::= a , b ::= c | s

  32. Source language: the located lambda calculus LM | λ a x . N | λ x . N | x | c L , M , N ::= a , b ::= c | s We eliminate un-located forms λ x . N by explicitly copying the location of their lexical context. So λ c x . L ( λ y . N ) becomes λ c x . L ( λ c y . N )

  33. Source language: the located lambda calculus LM | λ a x . N | x | c L , M , N ::= a , b ::= c | s We eliminate un-located forms λ x . N by explicitly copying the location of their lexical context. So λ a x . L ( λ y . N ) becomes λ c x . L ( λ c y . N )

  34. Semantics Read M ⇓ a V as ” M evaluates, starting at a , to V .” V ⇓ a V ( Value ) L ⇓ a λ b x . N M ⇓ a W N { W / x } ⇓ b V ( Beta ) LM ⇓ a V L ⇓ a c M ⇓ a W δ a ( c , W ) ⇓ a V ( Delta ) LM ⇓ a V

  35. Translation to a client-server system Three techniques: ◮ CPS translation: reifies the control state ◮ Defunctionalization: turns higher-order functions into data (serializable) ◮ Trampolining: inverts control, so state resides at client.

  36. CPS translation (due to Fischer, 1972, via Sabry and Wadler, 1997) Source: L , M , N ::= LM | V V ::= λ x . N | x CPS translation: ( LM ) † K L † ( λ f . M † ( λ x . fxK )) = V † K KV ◦ = ( λ x . N ) ◦ λ x .λ k . N † k = x ◦ = x

  37. Defunctionalization

  38. Defunctionalization target D ::= letrec D and · · · and D ::= f ( � x ) = case x of A D A ::= a set of A items F ( � A ::= c ) ⇒ M f ( � M ) | F ( � M ::= M ) | x | c

  39. Defunctionalization target D ::= letrec D and · · · and D ::= f ( � x ) = case x of A D A ::= a set of A items F ( � A ::= c ) ⇒ M f ( � M ) | F ( � M ::= M ) | x | c function names f , g constructor names F , G

  40. Defunctionalization (orig. Reynolds, 1972) ] fun ∗ ] top [ [ M ] = letrec apply ( fun , arg ) = case fun of [ [ M ] in [ [ M ] ] ] fun � λ x . N � ( � [ [ λ x . N ] = y ) ⇒ [ [ N ] ] { arg / x } where � y = fv ( λ x . N ) [ [ LM ] ] = apply ([ [ L ] ] , [ [ M ] ]) V ◦ [ [ V ] ] = ( λ x . N ) ◦ = � λ x . N � ( � y ) where � y = fv ( λ x . N ) x ◦ = x The operation � M � gives an opaque identifier for the term M .

  41. Trampolining (due to Ganz, Friedman and Wand) ◮ Continually returns control to a top-level trampoline ; ◮ Works on any tail-form program, including CPS programs; ◮ Choice of the trampoline modifies the behavior.

  42. Trampolining ( LM ) T Bounce ( λ z . L t M t ) = (where z is a dummy) V T Return ( V t ) = ( λ x . N ) t λ x . N T = x t = x Behavior depends on our choice of tramp .

  43. Example trampolines Trivial trampoline: tramp ( x ) = case x of Bounce ( thunk ) ⇒ tramp ( thunk ()) | Return ( x ) ⇒ x

  44. Example trampolines Trivial trampoline: tramp ( x ) = case x of Bounce ( thunk ) ⇒ tramp ( thunk ()) | Return ( x ) ⇒ x Step-counting trampoline: tramp ( n , x ) = case x of Bounce ( thunk ) ⇒ print ( n ); tramp ( n + 1 , thunk ()) | Return ( x ) ⇒ x

  45. Our trampoline Since the control state is reified, tramp can split the computation into a client- and a server-side piece. tramp ( x ) = case x of | Bounce ( f , x , k ) ⇒ tramp ( req cont ( k , apply ( f , x ))) | Return ( x ) ⇒ x (This shouldn’t make sense yet; don’t worry.)

  46. Our trampoline Since the control state is reified, tramp can split the computation into a client and a server-side piece. tramp ( x ) = case x of | Call ( f , x , k ) ⇒ tramp ( req cont ( k , apply ( f , x ))) | Return ( x ) ⇒ x (This shouldn’t make sense yet; don’t worry.)

  47. The Big Transformation

  48. First, the target: first-order client-server calculus

  49. The client-server calculus Syntax configurations K ::= ( M ; · ) | ( E ; M ) x | c | F ( � M ) | f ( � M ) | req f ( � terms L , M , N ::= M ) definition set D , C , S ::= letrec D and · · · and D function definitions ::= f ( � x ) = case M of A D alternative sets A a set of A items case alternatives ::= F ( � x ) ⇒ M A function names f , g constructor names F , G

  50. Configurations of the machine

  51. Semantics Client: ( E [ f ( � ( E [ M { � V )]; · ) − → C , S V /� x } ]; · ) if ( f ( � x ) = M ) ∈ C ( E [ case ( F ( � ( E [ M { � V )) of A ]; · ) − → C , S V /� x } ]; · ) if ( F ( � x ) ⇒ M ) ∈ A Server: ( E ; E ′ [ f ( � ( E ; E ′ [ M { � V )]) − → C , S V /� x } ]) if ( f ( � x ) = M ) ∈ S ( E ; E ′ [ case ( F ( � ( E ; E ′ [ M { � V )) of A ]) − → C , S V /� x } ]) if ( F ( � x ) ⇒ M ) ∈ A Communication: ( E [ req f ( � ( E ; f ( � V )]; · ) − → C , S V )) ( E ; V ) − → C , S ( E [ V ]; · )

  52. Now, the translation

  53. Transformation on terms ( λ a x . N ) ◦ � λ a x . N � ( � y = fv ( λ a x . N ) = y ) � x ◦ = x c ◦ = c V ∗ V ◦ = ( LM ) ∗ apply ( L ∗ , M ∗ ) = V † [ ] cont ([ ] , V ◦ ) = ( LM ) † [ ] L † ( � M � ( � where � = y , [ ])) y = fv ( M )

Recommend


More recommend