Structural Typing for Structured Products

Transcription

1 Structural Typing for Structured Products Tim Williams Peter Marks 8th October 2014

2 Background The FPF Framework A standardized representation for describing payoffs A common suite of tools for trades which use this representation UI for providing trade parameters Mathematical document descriptions Pricing and risk management Barrier analysis Payments and other lifecycle events 1

3 FPF Lucid A DSL for describing exotic payoffs and strategies Control constructs based around schedules Produces abstract syntax allowing multiple interpretations Damas-Hindley-Milner type inference with constraints and polymorphic extensible row types 2

4 Lucid language Articulation driven design 3

5 Lucid language Articulation driven design Lucid type system Structural typing with Row Polymorphism 4

6 A simple numeric expression exp(x) 5

7 A simple numeric expression Monomorphic exp(x) exp : Double Double x : Double exp(x) : Double 6

8 A conditional expression c x y 7

9 A conditional expression c x y Polymorphic if _ then _ else _ : (Bool, a, a) a c : Bool x : a y : a if c then x else y : a Hindley-Milner type system 8

10 Overloaded numeric literal x

11 Overloaded numeric literal Subtyping x + 42 (+) : (Num, Num) Num 42 : Integer x : Num x + 42 : Num Subtyping constraints difficult to solve with full inference A complex extension to Hindley-Milner 10

12 Overloaded numeric literal x + 42 Polymorphic with type variable constraints (+) : Num a (a, a) a 42 : Num a a x : Num a a x + 42 : Num a a Any type variable can have a single constraint Unifier ensures constraints are met Simple extension to Hindley-Milner 11

13 A simple Lucid function capfloor(perf, cap, floor) max(floor, min(cap, perf)) 12

14 A simple Lucid function capfloor(perf, cap, floor) max(floor, min(cap, perf)) capfloor : Num a (a, a, a) a 13

15 A simple Lucid function capfloor(perf, cap, floor) max(floor, min(cap, perf)) capfloor : Num a (a, a, a) a capfloor(perf, 0, 1) Not obvious which argument when applying function 14

16 Grouping and labelling arguments capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) 15

17 Grouping and labelling arguments Records via Nominal typing capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) data Num a CapFloor a = CapFloor {cap : a, floor : a } capfloor : Num a (a, CapFloor a) a 16

18 Grouping and labelling arguments Records via Nominal typing capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) data Num a CapFloor a = CapFloor {cap : a, floor : a } capfloor : Num a (a, CapFloor a) a Don t want to force users to define data types 17

19 Grouping and labelling arguments Records via Nominal typing capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) data Num a CapFloor a = CapFloor {cap : a, floor : a } capfloor : Num a (a, CapFloor a) a Don t want to force users to define data types Don t want to force users to name a combination of fields 18

20 Grouping and labelling arguments Records via Nominal typing capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) data Num a CapFloor a = CapFloor {cap : a, floor : a } capfloor : Num a (a, CapFloor a) a Don t want to force users to define data types Don t want to force users to name a combination of fields Want to use the same fields in different data types 19

21 Grouping and labelling arguments capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) Structural record types capfloor : Num a (a, {cap : a, floor : a}) a 20

22 Grouping and labelling arguments capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) Structural record types capfloor : Num a (a, {cap : a, floor : a}) a capfloor(perf, {cap=0, floor=1}) capfloor(perf, {floor=1, cap=0}) Unifier is agnostic to field order 21

23 Grouping and labelling arguments Structural record types capfloor(perf, {cap, floor}) max(floor, min(cap, perf)) capfloor : Num a (a, {cap : a, floor : a}) a capfloor(perf, {cap=0, floor=1}) capfloor(perf, {floor=1, cap=0}) Unifier is agnostic to field order Note the above is still not quite what Lucid infers 22

24 Grouping and labelling arguments Structural record types capfloor(perf, r) max(floor, min(r.cap, r.perf)) capfloor : Num a (a, {cap : a, floor : a}) a capfloor(perf, {cap=0, floor=1}) capfloor(perf, {floor=1, cap=0}) Unifier is agnostic to field order Note the above is still not quite what Lucid infers Pattern matching is just syntactic sugar for field selection 23

25 Ignoring additional fields kgcf(perf, r) capfloor( r.part * (perf - r.strike), {cap = r.cap, floor = r.floor}) kgcf(perf, {part=1, strike=0.9, cap=0, floor=1.2}) 24

26 Ignoring additional fields kgcf(perf, r) capfloor(r.part * (perf - r.strike), r) kgcf(perf, {part=1, strike=0.9, cap=0, floor=1.2}) 25

27 Ignoring additional fields kgcf(perf, r) capfloor(r.part * (perf - r.strike), r) kgcf(perf, {part=1, strike=0.9, cap=0, floor=1.2}) Structural Record types capfloor : Num a (a, {cap : a, floor : a}) a kgcf : Num a (a, {part : a, strike : a, cap : a, floor : a}) a How do we allow a superset of fields to be passed to CapFloor? 26

28 Ignoring additional fields kgcf(perf, r) capfloor(r.part * (perf - r.strike), r) kgcf(perf, {part=1, strike=0.9, cap=0, floor=1.2}) Structural Record types capfloor : Num a (a, {cap : a, floor : a}) a kgcf : Num a (a, {part : a, strike : a, cap : a, floor : a}) a How do we allow a superset of fields to be passed to CapFloor? Subtyping would require a new type system and inference algorithm 27

29 Ignoring additional fields kgcf(perf, r) capfloor(r.part * (perf - r.strike), r) kgcf(perf, {part=1, strike=0.9, cap=0, floor=1.2}) Polymorphic extensible Records capfloor : Num a (a, {cap : a, floor : a r}) a kgcf : Num a (perf, {part : a, strike : a, cap : a, floor : a s}) a How do we allow a superset of fields to be passed to CapFloor? Subtyping would require a new type system and inference algorithm Can use parametric polymorphism by using a type variable to represent the remaining fields 28

30 Extending Records gcfbasket(perf, weights, r) kgcf( sumproduct(perfs, weights), {strike=1, part=r.part, cap=r.cap, floor=r.floor}) 29

31 Extending Records gcfbasket(perf, weights, r) kgcf(sumproduct(perfs, weights), {strike=1 r}) 30

32 Extending Records gcfbasket(perf, weights, r) kgcf(sumproduct(perfs, weights), {strike=1 r}) Polymorphic extensible Records kgcf : (Num a, s/part/strike/cap/floor) (a, {part : a, strike : a, cap : a, floor : a s}) a gcfbasket : (Num a, r/part/strike/cap/floor) (a, {part : a, cap : a, floor : a r}) a 31

33 Extending Records gcfbasket(perf, weights, r) kgcf(sumproduct(perfs, weights), {strike=1 r}) Polymorphic extensible Records kgcf : (Num a, s/part/strike/cap/floor) (a, {part : a, strike : a, cap : a, floor : a s}) a gcfbasket : (Num a, r/part/strike/cap/floor) (a, {part : a, cap : a, floor : a r}) a Type inference introduces lacks constraints on row variables 32

34 Row Polymorphism The idea of row (parametric) polymorphism is to use a type variable to represent any additional unknown fields: 1 gcfbasket : (Num a, r/part/strike/cap/floor) (a, {part : a, cap : a, floor : a r}) a 1 Row polymorphism can be implemented with or without the lacks predicate, depending on whether repeated (scoped) labels are desired. 33

35 Type constructors: Row kinds The empty row : ROW Extend a row type (one constructor per label): l : _ _ : ROW ROW 34

36 Type constructors: Records Construct a Record from a row type (gives product types, structurally): {_} : ROW 35

37 Primitive operations on Records Selection (_.l) : ar. (r/l) {l : a r} a Restriction (_ / l) : ar. (r/l) {l : a r} {r} Extension 2 {l=_ _} : ar. (r/l) (a, {r}) {l : a r} 2 Note that Record literals are desugared to record extension. 36

38 Enums and switching behaviour calcoffset(ccy) ccy == USD 3 ccy == JPY

39 Enums and switching behaviour calcoffset(ccy) ccy == USD 3 ccy == JPY 2 0 No way to limit the set of atoms that can be used 38

40 Enums and switching behaviour calcoffset(ccy) ccy == USD 3 ccy == JPY 2 0 No way to limit the set of atoms that can be used Forced to provide a default value in the else clause 39

41 Enums and switching behaviour calcoffset(ccy) ccy USD 3, JPY 2 40

42 Enums and switching behaviour Row polymorphism calcoffset(ccy) ccy USD 3, JPY 2 calcoffset : Num a USD, JPY a 41

43 Enums and switching behaviour Row polymorphism calcoffset(ccy) ccy USD 3, JPY 2 calcoffset : Num a USD, JPY a Enums can be implemented using row types with unit fields 42

44 Enums and switching behaviour Row polymorphism calcoffset(ccy) ccy USD 3, JPY 2 calcoffset : Num a USD, JPY a Enums can be implemented using row types with unit fields Note the top-level type is closed 43

45 Extending enums and reusing behaviour calcoffsetext(ccy) ccy GBP 3, otherwise c calcoffset(c) 44

46 Extending enums and reusing behaviour calcoffsetext(ccy) ccy GBP 3, otherwise c calcoffset(c) Polymorphic extensible cases calcoffset : Num a USD, JPY a calcoffsetext : Num a GBP, USD, JPY a c : USD, JPY 45

47 Extending enums and reusing behaviour calcoffsetext(ccy) ccy GBP 3, otherwise c calcoffset(c) Polymorphic extensible cases calcoffset : Num a USD, JPY a calcoffsetext : Num a GBP, USD, JPY a c : USD, JPY Composition of cases using delegation 46

48 Extending enums and reusing behaviour calcoffsetext(ccy) ccy GBP 3, otherwise c calcoffset(c) Polymorphic extensible cases calcoffset : Num a USD, JPY a calcoffsetext : Num a GBP, USD, JPY a c : USD, JPY Composition of cases using delegation Creates a new type containing a superset of fields 47

49 Extending enums and reusing behaviour calcoffsetext(ccy) ccy GBP 3, otherwise c calcoffset(c) Polymorphic extensible cases calcoffset : Num a USD, JPY a calcoffsetext : Num a GBP, USD, JPY a c : USD, JPY Composition of cases using delegation Creates a new type containing a superset of fields Flexibility similar to OOP subclassing, without giving up extensibility of functions 48

50 Limiting the behaviour of existing code calcoffset2(ccy) calcoffsetext( JPY ccy ) 49

51 Limiting the behaviour of existing code calcoffset2(ccy) calcoffsetext( JPY ccy ) Embedding calcoffsetext : Num a GBP, USD, JPY a calcoffset2 : Num a GBP, USD a 50

52 Limiting the behaviour of existing code calcoffset2(ccy) calcoffsetext( JPY ccy ) Embedding calcoffsetext : Num a GBP, USD, JPY a calcoffset2 : Num a GBP, USD a Embedding adds JPY to the type and restricts its values as possible input 51

53 Overriding existing behaviour calcoffsetext2(ccy) ccy override USD 4, otherwise c calcoffsetext(c) 52

54 Overriding existing behaviour Embedding calcoffsetext2(ccy) ccy override USD 4, otherwise c calcoffsetext(c) calcoffsetext : Num a GBP, USD, JPY a calcoffsetext2 : Num a GBP, USD, JPY a c : GBP, USD, JPY Override is syntactic sugar for embedding in the otherwise clause 53

55 Optional arguments calcbasket(perfs, aggregation, weights) aggregation Worst minarray(perfs), Best maxarray(perfs), Weighted sumproduct(perfs, weights) 54

56 Optional arguments calcbasket(perfs, aggregation, weights) aggregation Worst minarray(perfs), Best maxarray(perfs), Weighted sumproduct(perfs, weights) The weights argument is only used in the Weighted case 55

57 Optional arguments calcbasket(perfs, aggregation) aggregation Worst minarray(perfs), Best maxarray(perfs), Weighted(weights) sumproduct(perfs, weights) The weights argument is only used in the Weighted case 56

58 Optional arguments Variants calcbasket(perfs, aggregation) aggregation Worst minarray(perfs), Best maxarray(perfs), Weighted(weights) sumproduct(perfs, weights) The weights argument is only used in the Weighted case calcbasket : r/worst/best/weighted (double[n], Worst, Best, Weighted : double[n] r ) double Note that array sizes are also represented with a type variable 57

59 Type constructors: Records and Variants Construct a record from a row type (gives product types, structurally): {_} : ROW Construct a variant from a row type (gives sum types, structurally): _ : ROW 58

60 Primitive operations on Variants Injection (dual of selection) l=_ : ar. (r/l) a l : a r Embedding (dual of restriction) l _ : ar. (r/l) r l : a r Decomposition (dual of extension) l _?_:_ : abr. (r/l) l : a r a r 59

61 Primitive operations on Variants Injection (dual of selection) l=_ : ar. (r/l) a l : a r (_.l) : ar. (r/l) {l : a r} a Embedding (dual of restriction) l _ : ar. (r/l) r l : a r (_ / l) : ar. (r/l) {l : a r} {r} Decomposition (dual of extension) l _?_:_ : abr. (r/l) l : a r a r {l=_ _} : ar. (r/l) (a, {r}) {l : a r} 60

62 Decomposition (fused with a fold on the coproduct) 3 case _ of l _, otherwise _ : abr. (r/l) ( l : a r, a b, r b) b The empty alternative is used to close variants: emptyalt : b 3 Note that the case construct provides a notion of type refinement. 61

63 Tracking Effects paysomething(amt, sched, settl) sched Coupon amt settl 62

64 Tracking Effects paysomething(amt, sched, settl) sched Coupon amt settl Row-polymorphic effect types paysomething : (double, schedule, settlement) {payments} () Use row types to add an effect parameter to every function abe. a {e} b Only consider effects that are intrinsic to the language. Assume strict semantics, a function call inherits the effects from evaluation of its arguments. 63

65 Lacks constraint to restrict effects We want to prevent users from making payments in case alternatives, as conditional payments must be handled via other primitives: case _ of l _, otherwise _ : abre. (r/l, e/payments) ( l : a r, a {e} b, r b) b Note that we omit all unconstrained effect row variables. 64

66 An example Lucid function type autocallable : { asset : asset, fixedcouponamt : double, asianinschedule : schedule, asianoutschedule : schedule, couponschedule : schedule, autocallschedule : schedule, digitalcouponparams : { direction : <Up, Down, StrictlyUp, StrictlyDown>, level : double, amount : double }, perfcouponoption : { type : <Call, Put, Forward, Straddle, Const>, strike : double, part : double }, autocallparams : { direction : <Up, Down, StrictlyUp, StrictlyDown>, level : double, amount : double }, maturitydate : schedule, finalredemptionamt : double, kischedule : schedule, kibarrierparams : { direction : <Up, Down, StrictlyUp, StrictlyDown>, level : double }, kioption : { type : <Call, Put, Forward, Straddle, Const>, strike : double, part : double } } -> {payments, exit} () 65

67 Structural Typing Type equivalence determined by the type s actual structure, not by e.g. a name as in nominal typing. Research literature is almost completely concerned with structural type systems (TAPL 2002) 66

68 Benefits Permits sharing of constructors/labels amongst different types 67

69 Benefits Permits sharing of constructors/labels amongst different types Allows reuse of code across different (extended) types 68

70 Benefits Permits sharing of constructors/labels amongst different types Allows reuse of code across different (extended) types No requirement or dependency on type definitions or declarations, types can be fully inferred from their usage and are self-describing 69

71 Benefits Permits sharing of constructors/labels amongst different types Allows reuse of code across different (extended) types No requirement or dependency on type definitions or declarations, types can be fully inferred from their usage and are self-describing Creation of a Nominal type from a Structural type, just requires newtype or similar. The inverse is not so easy. 70

72 Benefits Permits sharing of constructors/labels amongst different types Allows reuse of code across different (extended) types No requirement or dependency on type definitions or declarations, types can be fully inferred from their usage and are self-describing Creation of a Nominal type from a Structural type, just requires newtype or similar. The inverse is not so easy. Combines the flexibility of unityping, with the safety of nominal typing 71

73 Benefits Permits sharing of constructors/labels amongst different types Allows reuse of code across different (extended) types No requirement or dependency on type definitions or declarations, types can be fully inferred from their usage and are self-describing Creation of a Nominal type from a Structural type, just requires newtype or similar. The inverse is not so easy. Combines the flexibility of unityping, with the safety of nominal typing Achieves the composition of data-types that we see in frameworks like Data types à la carte 72

74 Structural Typing in Haskell Haskell vanilla ADTs and Records are nominally typed We regularly see the tension of e.g. Tuples/HList versus Records. But Haskell essentially uses structural typing exclusively for functions: Haskell Java (Nominal) () -> IO () class Runnable { void run() } a -> a -> Ordering class Comparator { int compare(t, T) } a -> b class Function<? super T,? extends R> { R apply(t) } 73

75 An example type checker 74

76 References [1] B. R. Gaster, M. P. Jones, A Polymorphic Type System for Extensible Records and Variants, 1996 [2] J. Garrigue, Programming with Polymorphic Variants, 1998 [3] J. Garrigue, Code reuse through polymorphic variants, 2000 [4] D. Leijen, Extensible records with scoped labels, 2005 [5] D. Leijen, Koka : Programming with Row-polymorphic Effect Types,