Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Parametricity and other principles - CompCon 2015

Parametricity and other principles - CompCon 2015

Presentation to university students about parametricity and other important principles for working programmers, at CompCon 2015.

7c0f9b056604fe541691e18aeb679cf7?s=128

Fraser Tweedale

October 04, 2015
Tweet

More Decks by Fraser Tweedale

Other Decks in Programming

Transcript

  1. Parametricity and other principles Fraser Tweedale @hackuador October 4, 2015

  2. Intro

  3. Target audience Software developers whose goals are: Correct software Maintainable

    software Still correct after maintenance Move fast and don’t break things
  4. Move fast and break things? “When you build something that

    you don’t have to fix 10 times, you can move forward on top of what you’ve built. It may not be quite as catchy as ‘move fast and break things’ but it’s how we operate now.” Mark Zuckerberg http://is.gd/vx3tgj
  5. Outline Principles and tools for the working programmer Lots of

    opinions Mine, not my employer’s Some facts May contain traces of unfamiliar syntax Manufactured on equipment that also processes tree nuts
  6. Language survey

  7. On correctness

  8. Correctness Doesn’t matter that much right? “But I’m only ever

    going to write _______” web things? boring business logic? games? Broken software has consequences Start caring; embrace the tools
  9. Data modelling Model data responsibly Do your research Falsehoods programmers

    believe about {names, time, . . . } Make illegal state unrepresentable Newtypes, units of measure Immutability
  10. Dynamic vs static typing

  11. Dynamically typed languages Duck typing, type juggling, argh! Checking argument

    “types” is boring yet fraught Little help with program construction, refactoring Type checkers eliminate whole classes of errors for free Principled abstractions. . . where are they?
  12. Criticisms of static typing Too verbose Types can’t capture the

    information in docs Types can’t catch all errors I need rapid feedback and the ability to prototype quickly But I like {Python, JavaScript, . . . }!
  13. Verbosity # Python print("Enter your name: ", end=’’) name =

    input() print("Hi, " + name) -- Haskell main = do putStr "Enter your name: " name <- getLine putStrLn ("Hi, " ++ name)
  14. Type system expressiveness

  15. Type system expressiveness

  16. Prototyping

  17. Warm, fuzzy feelings

  18. Type safety “People first need to feel the pain of

    runtime errors to understand why a type system is useful.” Python aficionado
  19. Why don’t my programs work?

  20. Escape hatches null values type casing (instanceof) type casting exceptions

    general recursion side-effects (I/O, impure functions)
  21. Trap

  22. I know what you’re thinking How will I do X

    without feature Y?
  23. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y?
  24. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects?
  25. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects?
  26. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful?
  27. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis)
  28. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this.
  29. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this. No you don’t (and neither do I).
  30. I know what you’re thinking How will I do X

    without feature Y? How will I reason about your program to do X if you use Y? What use is a program without side effects? What use is a program with uncontrolled side effects? What about algorithms that are inherently stateful? They don’t exist. (Church-Turing thesis) It’s fine, I’ve got this. No you don’t (and neither do I). Apologise to your team mates and future-self right now.
  31. Total languages languages that guarantee program termination examples: Agda, Coq,

    Idris can express most programs (all that we care about in industry) most programmers are using non-total languages
  32. Fast and loose reasoning reasoning about programs written in non-total

    langauges as if they were written in a total language. justified (mathematically) in Fast and loose reasoning is morally correct, Danielsson et al. 2006 costs nothing; you can write any program without using escape hatches and you gain composability referential integrity equational reasoning reuse
  33. Parametricity

  34. Parametric polymorphism (syntax) // Java generics static <A> List<A> f(List<A>

    xs) { ... } # Python (with PEP 484 type hinting) def f(xs : List[T]) -> List[T]: ... -- Haskell f :: [a] -> [a] f xs = ...
  35. Parametric polymorphism Two function signatures: f :: [Int] -> [Int]

    g :: [ a ] -> [ a ] Which gives the programmer more information? Which is better?
  36. Theorems for Free!

  37. Parametricity “Write down the definition of a polymorphic function on

    a piece of paper. Tell me its type, but be careful not to let me see the function’s definition. I will tell you a theorem that the function satisfies.” Theorems for Free! Wadler 1989 Polymorphic types are: partial (sometimes complete) specifications implementor cannot use any type-specific behaviour caller has guarantee function will work for any type machine-checkable documentation a free source of useful theorems (parametricity)
  38. Parametricity f :: [a] -> [a] What does this function

    do? reverse a list?
  39. Parametricity f :: [a] -> [a] What does this function

    do? reverse a list? drop the first element?
  40. Parametricity f :: [a] -> [a] What does this function

    do? reverse a list? drop the first element? ignore its argument return an empty list?
  41. Parametricity f :: [a] -> [a] What does this function

    do? reverse a list? drop the first element? ignore its argument return an empty list? Theorem: every element in the output appears in the input
  42. Parametricity f :: [a] -> [a] What does this function

    do? reverse a list? drop the first element? ignore its argument return an empty list? Theorem: every element in the output appears in the input Theorem: ∀ g. map g ◦ f = f ◦ map g
  43. Parametricity f :: a -> (a, a) g :: a

    -> a -> a h :: b -> a -> a https://twitter.com/parametricity
  44. Testing

  45. Testing Who writes tests? Who likes writings tests? Ever missed

    a corner case?
  46. Testing Recall our old friend: f :: [a] -> [a]

    It turns out we do want f to reverse lists Alas! ([a] -> [a]) does not mean reverse
  47. Testing ∀ x. f [x] = [x] ∀ xs ys.

    f (xs ++ ys) = f ys ++ f xs f :: [a] -> [a] Now we’re good. A minimal (yet complete) algebraic specification for list reversal
  48. Property-based testing write down properties of your functions tell the

    framework how to generate random values framework generates lots of data, tries to falsify properties the best test data is random test data QuickCheck: A Lightweight Tool for Random Testing of Haskell Programs. Claessen and Hughes 2000 Talk: https://youtu.be/TSDTDqoH_vM
  49. Theorem proving the best test data is no test data

    proof assistants: Agda, Coq, Idris no proof, no program can prove correctness, equivalence, complexity, . . . program extraction to other languages Idris talk/demo: https://youtu.be/4i7KrG1Afbk
  50. Theorem proving “Beware of bugs in the above code; I

    have only proved it correct, not tried it.” Donald Knuth
  51. Theorem proving “We are waiting for you to catch up,

    so we can employ you.” anonymous, NICTA (data61)
  52. Wrapping up

  53. Excuses But we are a {Java, C#, . . .

    } shop! We won’t be able to hire {Haskell, Scala, . . . } devs! The academic-ness, it burns!
  54. Languages Scala, Frege, Clojure, Ermine (JVM) F# (Common Language Infrastructure)

    Swift (iThings) Do you really need to stick to {JVM, CLI}? Haskell, Rust
  55. Libraries functionaljava scalaz swiftz xsharpx (C#)

  56. Resources Brisbane Functional Programming Group http://bfpg.org/ #bfpg on Freenode or

    find an FP group in your city https://github.com/NICTA/course Software Foundations Course on mathematical underpinnings of reliable software http://www.cis.upenn.edu/~bcpierce/sf
  57. Conclusion Responsible modelling of data is paramount Types are your

    friend Avoid traps and use fast and loose reasoning Parametric polymorphism gives you theorems for free Algebraic properties → more thorough tests with less effort Use the right tools
  58. Fin Copyright 2015 Fraser Tweedale This work is licensed under

    the Creative Commons Attribution 4.0 International License. To view a copy of this license, visit http://creativecommons.org/licenses/by/4.0/. Slides https://github.com/frasertweedale/talks/ Twitter @hackuador Email frase@frase.id.au