A Step-Indexed Model of Substructural State

1. A Step-Indexed Model of Substructural State Matthew Fluet Cornell University Amal Ahmed Greg Morrisett Harvard University

2. A Step-Indexed Model ofSubstructural State Matthew Fluet Cornell University Amal Ahmed Greg Morrisett Harvard University

3. Introduction • Mutable state is here to stay

4. Introduction • Mutable state is here to stay • high-level – I/O, data structures • low-level – virtual machines, garbage collector

5. Introduction • Mutable state is hard to control

6. Introduction • Mutable state is hard to control • C / Java / SML – unrestricted objects

7. Introduction • Mutable state is hard to control • Various forms of uniqueness have appeared as a means to “tame” state

8. Introduction • Mutable state is hard to control • Various forms of uniqueness have appeared as a means to “tame” state • Clean – uniqueness types • I/O operations in a purely-functional language • Cyclone – unique pointers • fine-grained memory management • Vault – unique keys • resource management protocols

9. Introduction • Mutable state is hard to control • Various forms of uniqueness have appeared as a means to “tame” state • Clean – uniqueness types • I/O operations in a purely-functional language • Cyclone – unique pointers • fine-grained memory management • Vault – unique keys • resource management protocols

10. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive

11. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Only tree-like data structures • Only single paths to a unique object

12. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Only tree-like data structures • Only single paths to a unique object fun f () = … lr … fun g () = … lr … lr -- unique resource

13. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Only tree-like data structures • Only single paths to a unique object fun f () = … lr … fun g () = … lr … lr -- unique resource

14. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects

15. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects fun f () = … ls … fun g () = … ls … ls lr -- shared object lr -- unique resource

16. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions

17. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions Cyclone and Vault have different interpretations of “unique” and “shared”

18. Introduction • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions Cyclone and Vault have different interpretations of “unique” and “shared” So, they have different sets of restrictions(i.e., type-systems)

19. Introduction How do we compare and evaluate these languages? • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions Cyclone and Vault have different interpretations of “unique” and “shared” So, they have different sets of restrictions(i.e., type-systems)

20. Introduction Can we generalize the interpretations and restrictions? • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions Cyclone and Vault have different interpretations of “unique” and “shared” So, they have different sets of restrictions(i.e., type-systems)

21. Introduction Can we definean expressivetarget language? • Mutable state is hard to control • Unique objects alone are too restrictive • Cyclone and Vault allow programs to store unique objects in shared objects • Safety of mixed objects requires some restrictions Cyclone and Vault have different interpretations of “unique” and “shared” So, they have different sets of restrictions(i.e., type-systems)

22. Introduction • We study a core language with mutable references

23. Introduction • We study a core language with mutable references • deallocation of references • strong (type-varying) updates • storage of unique objects in shared references

24. Introduction • We study a core language with mutable references of all qualifiers

25. Introduction • We study a core language with mutable references of all qualifiers • Unrestricted – like C / Java / SML • Affine – like Clean and Cyclone • Linear – like Vault

26. Introduction • We study a core language with mutable references of all qualifiers • Unrestricted – like C / Java / SML • Relevant • Affine – like Clean and Cyclone • Linear – like Vault

27. Introduction • We study a core language with mutable references of all qualifiers • Unrestricted – like C / Java / SML • Relevant • Affine – like Clean and Cyclone • Linear – like Vault

28. Outline • A Substructural Type System • … with References • Model Teaser

29. Structural Properties • Conventional type systems satisfy • Exchange • use typing assumptions in any order • Contraction • use typing assumptions more than once • Weakening • use typing assumptions less than once

30. Structural Properties • Conventional type systems satisfy • Exchange • use typing assumptions in any order • Contraction – Copy • use typing assumptions more than once • Weakening – Drop • use typing assumptions less than once

31. Structural Properties • Substructural type systems fail to satisfy • Exchange • use typing assumptions in any order • Contraction – Copy • use typing assumptions more than once • Weakening – Drop • use typing assumptions less than once

32. Structural Properties • Substructural type systems fail to satisfy • Exchange • use typing assumptions in any order • Contraction – Copy • use typing assumptions more than once • Weakening – Drop • use typing assumptions less than once

33. Substructural Qualifiers Linear Affine Drop Relevant Copy Unrestricted Drop Copy

34. Substructural Qualifiers Unique objects – may be “used”at most once Linear Affine Drop Relevant Copy Unrestricted Drop Copy Shared objects – may be “used” more than once

35. Substructural Qualifiers Unique objects – may be “used”at most once Linear Affine Drop Relevant Copy Unrestricted Drop Copy Shared objects – may be “used” more than once

36. Substructural Qualifiers Unique objects – may be “used”at most once Linear Affine Drop Relevant Copy Unrestricted Drop Copy Shared objects – may be “used” more than once

37. Substructural Qualifiers Unique objects – may be “used”at most once Linear Affine Drop Relevant Copy Unrestricted Drop Copy Shared objects – may be “used” more than once

38. Substructural Qualifiers Essential objects – must be “used”at least once Linear Affine Drop Relevant Copy Inessential objects – may be “used” less than once Unrestricted Drop Copy

39. Substructural Qualifiers Essential objects – must be “used”at least once Linear Affine Drop Relevant Copy Inessential objects – may be “used” less than once Unrestricted Drop Copy

40. Substructural Qualifiers Essential objects – must be “used”at least once Linear Affine Drop Relevant Copy Inessential objects – may be “used” less than once Unrestricted Drop Copy

41. Substructural Qualifiers Essential objects – must be “used”at least once Linear Affine Drop Relevant Copy Inessential objects – may be “used” less than once Unrestricted DropCopy

42. A Substructural Type System • Qualifiers q ::= U j R j A j L • PreTypes t::= 1jt1­t2jt1(t2 • Types t::= qt

43. A Substructural Type System • Qualifiers q ::= U j R j A j L • PreTypes t::= 1jt1­t2jt1(t2 • Types t::= qt How maythe value be used?

44. A Substructural Type System • Qualifiers q ::= U j R j A j L • PreTypes t::= 1jt1­t2jt1(t2 • Types t::= qt How often maythe value be used? How maythe value be used?

45. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2) U(At1­At2) 

46. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2) U(At1­At2)  hv1, v2i may be used more than once

47. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2) U(At1­At2)  hv1, v2i may be used more than once

48. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2) U(At1­At2)  v1 and v2 may be used more than once

49. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2) U(At1­At2)  v1 and v2 may be used more than once

50. Copy with Pairs copyUhLv1,Lv2i!hUhLv1,Lv2i, UhLv1,Lv2ii U(Lt1­Lt2)U(At1­At2) 