pure functional programming
play

Pure Functional Programming Functional Programming and Reasoning Dr - PowerPoint PPT Presentation

Dec 22, 2022 •461 likes •1.6k views

Pure Functional Programming Functional Programming and Reasoning Dr Hans Georg Schaathun University of Surrey Spring 2010 Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 1 / 52 Outline Testing and Proof 1 Pure Functional

  1. Testing and Proof A little logic A little logic Consider a statement such as Sheep are white 1 Therefore, Dolly the Sheep is white 2 This is an implication There is an assumption (1) and a consequence (2) The validity of the assumption is uncertain But if the assumption is true, there is no option for the consequence Also note that if (2) is false then (1) must be false Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 14 / 52

  2. Testing and Proof A little logic A little logic Consider a statement such as Sheep are white 1 Therefore, Dolly the Sheep is white 2 This is an implication There is an assumption (1) and a consequence (2) The validity of the assumption is uncertain But if the assumption is true, there is no option for the consequence Also note that if (2) is false then (1) must be false Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 14 / 52

  3. Testing and Proof A little logic A little logic Consider a statement such as Sheep are white 1 Therefore, Dolly the Sheep is white 2 This is an implication There is an assumption (1) and a consequence (2) The validity of the assumption is uncertain But if the assumption is true, there is no option for the consequence Also note that if (2) is false then (1) must be false Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 14 / 52

  4. Testing and Proof A little logic A little logic Consider a statement such as Sheep are white 1 Therefore, Dolly the Sheep is white 2 This is an implication There is an assumption (1) and a consequence (2) The validity of the assumption is uncertain But if the assumption is true, there is no option for the consequence Also note that if (2) is false then (1) must be false Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 14 / 52

  5. Testing and Proof A little logic A little logic Consider a statement such as Sheep are white 1 Therefore, Dolly the Sheep is white 2 This is an implication There is an assumption (1) and a consequence (2) The validity of the assumption is uncertain But if the assumption is true, there is no option for the consequence Also note that if (2) is false then (1) must be false Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 14 / 52

  6. Testing and Proof A little logic Logical Notation Sheep are white ⇒ Dolly the Sheep is white Dolly the Sheep is white ⇐ Sheep are white Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 15 / 52

  7. Testing and Proof A little logic Logical Notation Sheep are white ⇒ Dolly the Sheep is white Dolly the Sheep is white ⇐ Sheep are white Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 15 / 52

  8. Testing and Proof A little logic Checking the Validity Two separate questions Is the assumption (1) true? 1 Is the inference ( ⇒ ) valid? 2 The consequence (2) follows if both answers are yes Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 16 / 52

  9. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  10. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  11. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  12. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  13. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  14. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  15. Testing and Proof A little logic Deduction Sheep are white ⇒ Dolly the Sheep is white Example of Deduction i.e. a valid inference W be the set of all white things S be the set of all sheep d ∈ S is Dolly the Sheep We have assumed S ⊂ W We have d ∈ S ⊂ W Hence d ∈ W Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 17 / 52

  16. Testing and Proof A little logic Induction Generalisation for a special case Dolly the Sheep is white ⇒ Sheep are white This would be an invalid inference (generalising from a special case) Known as induction Attempts to generalise from specific information Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 18 / 52

  17. Testing and Proof A little logic Induction Generalisation for a special case Dolly the Sheep is white ⇒ Sheep are white This would be an invalid inference (generalising from a special case) Known as induction Attempts to generalise from specific information Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 18 / 52

  18. Testing and Proof A little logic Induction Generalisation for a special case Dolly the Sheep is white ⇒ Sheep are white This would be an invalid inference (generalising from a special case) Known as induction Attempts to generalise from specific information Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 18 / 52

  19. Testing and Proof A little logic Learning by Observation Dolly is white Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 19 / 52

  20. Testing and Proof A little logic Learning by Observation All (?) sheep are white Not quite. Many sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 20 / 52

  21. Testing and Proof A little logic Learning by Observation All (?) sheep are white Not quite. Many sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 20 / 52

  22. Testing and Proof A little logic Learning by Observation Not all sheep are white Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 21 / 52

  23. Testing and Proof A little logic Learning by Observation Conclusion Observable. A white sheep exists. Not observable. All sheep are white. Observable. A non-white sheep exists. Observable. Not all sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 22 / 52

  24. Testing and Proof A little logic Learning by Observation Conclusion Observable. A white sheep exists. Not observable. All sheep are white. Observable. A non-white sheep exists. Observable. Not all sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 22 / 52

  25. Testing and Proof A little logic Learning by Observation Conclusion Observable. A white sheep exists. Not observable. All sheep are white. Observable. A non-white sheep exists. Observable. Not all sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 22 / 52

  26. Testing and Proof A little logic Learning by Observation Conclusion Observable. A white sheep exists. Not observable. All sheep are white. Observable. A non-white sheep exists. Observable. Not all sheep are white. Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 22 / 52

  27. Testing and Proof Testing and induction Outline Testing and Proof 1 Verifying programs A little logic Testing and induction Reason and deduction Pure Functional Programming 2 Definedness and Termination 3 Conclusion 4 Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 23 / 52

  28. Testing and Proof Testing and induction Testing does special cases only Program works for input dolly 1 Program works for any input (of type Sheep ) 2 The former is observable – by testing The latter cannot be tested And the induction ( 1 ) → ( 2 ) is not valid Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 24 / 52

  29. Testing and Proof Testing and induction Choosing test cases Black Box Testing Testing cannot prove that the program works but it can prove that it does not find the black sheep in the flock Choosing test cases is a key skill appropriate broad selection maximises the chances of finding a black sheep Black Box Testing choose test cases based on the specification with no knowledge of the implementation Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 25 / 52

  30. Testing and Proof Testing and induction Choosing test cases Black Box Testing Testing cannot prove that the program works but it can prove that it does not find the black sheep in the flock Choosing test cases is a key skill appropriate broad selection maximises the chances of finding a black sheep Black Box Testing choose test cases based on the specification with no knowledge of the implementation Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 25 / 52

  31. Testing and Proof Testing and induction Choosing test cases Black Box Testing Testing cannot prove that the program works but it can prove that it does not find the black sheep in the flock Choosing test cases is a key skill appropriate broad selection maximises the chances of finding a black sheep Black Box Testing choose test cases based on the specification with no knowledge of the implementation Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 25 / 52

  32. Testing and Proof Testing and induction Choosing test cases Black Box Testing Testing cannot prove that the program works but it can prove that it does not find the black sheep in the flock Choosing test cases is a key skill appropriate broad selection maximises the chances of finding a black sheep Black Box Testing choose test cases based on the specification with no knowledge of the implementation Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 25 / 52

  33. Testing and Proof Testing and induction Example: minThree minThree :: Int -> Int -> Int -> Int Returns the smallest of three integers Which inputs do we have to test? Three different numbers (small,middle,large); (small,large,middle); (large,middle,small); etc. Two equal + one smaller Two equal + one larger Three equal At least one test case from each category not so important to test both ( 1 , 2 , 3 ) and ( 1 , 2 , 4 ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 26 / 52

  34. Testing and Proof Testing and induction Example: minThree minThree :: Int -> Int -> Int -> Int Returns the smallest of three integers Which inputs do we have to test? Three different numbers (small,middle,large); (small,large,middle); (large,middle,small); etc. Two equal + one smaller Two equal + one larger Three equal At least one test case from each category not so important to test both ( 1 , 2 , 3 ) and ( 1 , 2 , 4 ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 26 / 52

  35. Testing and Proof Testing and induction Example: minThree minThree :: Int -> Int -> Int -> Int Returns the smallest of three integers Which inputs do we have to test? Three different numbers (small,middle,large); (small,large,middle); (large,middle,small); etc. Two equal + one smaller Two equal + one larger Three equal At least one test case from each category not so important to test both ( 1 , 2 , 3 ) and ( 1 , 2 , 4 ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 26 / 52

  36. Testing and Proof Reason and deduction Outline Testing and Proof 1 Verifying programs A little logic Testing and induction Reason and deduction Pure Functional Programming 2 Definedness and Termination 3 Conclusion 4 Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 27 / 52

  37. Testing and Proof Reason and deduction Analyse it Go general Testing and evaluation consider special cases Analytical argument aim to generalise Good argument is about being structured and systematic covering all cases This is about practice and talent so let’s go through an example Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 28 / 52

  38. Testing and Proof Reason and deduction Analyse it Go general Testing and evaluation consider special cases Analytical argument aim to generalise Good argument is about being structured and systematic covering all cases This is about practice and talent so let’s go through an example Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 28 / 52

  39. Testing and Proof Reason and deduction Analyse it Go general Testing and evaluation consider special cases Analytical argument aim to generalise Good argument is about being structured and systematic covering all cases This is about practice and talent so let’s go through an example Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 28 / 52

  40. Testing and Proof Reason and deduction Analyse it A sample function implementation Is the following a correct calculation of maximum? minThree x y z | x < y && x < z = x | y < x && y < z = y | otherwise = z Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 29 / 52

  41. Testing and Proof Reason and deduction Analyse it Continued 1 | x < y && x < z = x Clearly, x is strictly smaller than y and z . Correct. 2 | y < x && y < z = y Clearly, x is strictly smaller than x and z . Correct. Which cases remain for otherwise ? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 30 / 52

  42. Testing and Proof Reason and deduction Analyse it Continued 1 | x < y && x < z = x Clearly, x is strictly smaller than y and z . Correct. 2 | y < x && y < z = y Clearly, x is strictly smaller than x and z . Correct. Which cases remain for otherwise ? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 30 / 52

  43. Testing and Proof Reason and deduction Analyse it Continued 1 | x < y && x < z = x Clearly, x is strictly smaller than y and z . Correct. 2 | y < x && y < z = y Clearly, x is strictly smaller than x and z . Correct. Which cases remain for otherwise ? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 30 / 52

  44. Testing and Proof Reason and deduction Analyse it The otherwise cases We may have z < x and z < y , 1 when z is the correct output. We may have x = y = z , 2 when z is correct (as would x or y be) Cases with two equal inputs 3 ... next slide ... Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 31 / 52

  45. Testing and Proof Reason and deduction Analyse it The otherwise cases We may have z < x and z < y , 1 when z is the correct output. We may have x = y = z , 2 when z is correct (as would x or y be) Cases with two equal inputs 3 ... next slide ... Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 31 / 52

  46. Testing and Proof Reason and deduction Analyse it The otherwise cases We may have z < x and z < y , 1 when z is the correct output. We may have x = y = z , 2 when z is correct (as would x or y be) Cases with two equal inputs 3 ... next slide ... Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 31 / 52

  47. Testing and Proof Reason and deduction Analyse it Two equal inputs z = x z ≤ y : otherwise applies – correct z > y : Case 2 applies – correct z = y z ≤ x : otherwise applies – correct z > x : Case 1 applies – correct x = y z ≤ x : otherwise applies – correct z > x : otherwise applies – minimum is x (= y ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 32 / 52

  48. Testing and Proof Reason and deduction Analyse it Two equal inputs z = x z ≤ y : otherwise applies – correct z > y : Case 2 applies – correct z = y z ≤ x : otherwise applies – correct z > x : Case 1 applies – correct x = y z ≤ x : otherwise applies – correct z > x : otherwise applies – minimum is x (= y ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 32 / 52

  49. Testing and Proof Reason and deduction Analyse it Two equal inputs z = x z ≤ y : otherwise applies – correct z > y : Case 2 applies – correct z = y z ≤ x : otherwise applies – correct z > x : Case 1 applies – correct x = y z ≤ x : otherwise applies – correct z > x : otherwise applies – minimum is x (= y ) Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 32 / 52

  50. Testing and Proof Reason and deduction Analysis Summary We found the bug by carefully checking every case, class by class the classes cover all possible inputs Suppose there were no bug would this method allow us to prove correctness? Yes – we have not only found the bug we know exactly which inputs for which the output is wrong For each class of inputs, it is either correct or wrong and any possible inputs falls in at least one class Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 33 / 52

  51. Testing and Proof Reason and deduction Analysis Summary We found the bug by carefully checking every case, class by class the classes cover all possible inputs Suppose there were no bug would this method allow us to prove correctness? Yes – we have not only found the bug we know exactly which inputs for which the output is wrong For each class of inputs, it is either correct or wrong and any possible inputs falls in at least one class Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 33 / 52

  52. Testing and Proof Reason and deduction Analysis Summary We found the bug by carefully checking every case, class by class the classes cover all possible inputs Suppose there were no bug would this method allow us to prove correctness? Yes – we have not only found the bug we know exactly which inputs for which the output is wrong For each class of inputs, it is either correct or wrong and any possible inputs falls in at least one class Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 33 / 52

  53. Testing and Proof Reason and deduction Analysis Summary We found the bug by carefully checking every case, class by class the classes cover all possible inputs Suppose there were no bug would this method allow us to prove correctness? Yes – we have not only found the bug we know exactly which inputs for which the output is wrong For each class of inputs, it is either correct or wrong and any possible inputs falls in at least one class Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 33 / 52

  54. Testing and Proof Reason and deduction The bug fix How do you correct the bug in the code? (one way) replace < by <= in the guards Exercise: run through the analysis above for the corrected code are you convinced that the implementation is correct for any input? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 34 / 52

  55. Testing and Proof Reason and deduction The bug fix How do you correct the bug in the code? (one way) replace < by <= in the guards Exercise: run through the analysis above for the corrected code are you convinced that the implementation is correct for any input? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 34 / 52

  56. Testing and Proof Reason and deduction The bug fix How do you correct the bug in the code? (one way) replace < by <= in the guards Exercise: run through the analysis above for the corrected code are you convinced that the implementation is correct for any input? Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 34 / 52

  57. Testing and Proof Reason and deduction White Box Testing Black Box Testing consider the implementation as a black box no knowledge of the implementation White Box Testing analyse the implementation to choose test cases In particular, look at the guards when evaluation branches, use test sets for each branch This often helps adding important test cases otherwise forgotten Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 35 / 52

  58. Testing and Proof Reason and deduction White Box Testing Black Box Testing consider the implementation as a black box no knowledge of the implementation White Box Testing analyse the implementation to choose test cases In particular, look at the guards when evaluation branches, use test sets for each branch This often helps adding important test cases otherwise forgotten Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 35 / 52

  59. Testing and Proof Reason and deduction White Box Testing Black Box Testing consider the implementation as a black box no knowledge of the implementation White Box Testing analyse the implementation to choose test cases In particular, look at the guards when evaluation branches, use test sets for each branch This often helps adding important test cases otherwise forgotten Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 35 / 52

  60. Testing and Proof Reason and deduction White Box Testing Black Box Testing consider the implementation as a black box no knowledge of the implementation White Box Testing analyse the implementation to choose test cases In particular, look at the guards when evaluation branches, use test sets for each branch This often helps adding important test cases otherwise forgotten Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 35 / 52

  61. Pure Functional Programming Outline Testing and Proof 1 Pure Functional Programming 2 Definedness and Termination 3 Conclusion 4 Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 36 / 52

  62. Pure Functional Programming Pure functional language Haskell is a pure functional language therefore, lends itself well to reasoning It adhers to a strict set of principles contrary to languages providing imperative and functional features together Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 37 / 52

  63. Pure Functional Programming What is a program Functional : list of definitions one expression being evaluated at the end Imperative : list of instructions executed one by one modifying variables (system state) Time is important in imperative programming instructions are executed in order and instructions can redefine objects Definitions are constant in functional programming nothing changes over time Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 38 / 52

  64. Pure Functional Programming Referential transparency All calls to the same function same input ⇒ same output Two major benefits the compiler can optimise (avoid recomputation) the developer can make mathematical proofs This is not true for imperative programming as functions may depend on the system state (variables) such dependencies may be hard to spot, and makes reasoning more difficult Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 39 / 52

  65. Pure Functional Programming Referential transparency All calls to the same function same input ⇒ same output Two major benefits the compiler can optimise (avoid recomputation) the developer can make mathematical proofs This is not true for imperative programming as functions may depend on the system state (variables) such dependencies may be hard to spot, and makes reasoning more difficult Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 39 / 52

  66. Pure Functional Programming Referential transparency All calls to the same function same input ⇒ same output Two major benefits the compiler can optimise (avoid recomputation) the developer can make mathematical proofs This is not true for imperative programming as functions may depend on the system state (variables) such dependencies may be hard to spot, and makes reasoning more difficult Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 39 / 52

  67. Pure Functional Programming Side-effects Functions have no side-effect all communication is via the output cannot modify behaviour of other functions cannot do Input/Output (IO) directly cannot modify variables Pure functional languages forbid side-effects completely Avoiding side-effects is good practice easier to reuse code other applications often need same return value different side-effects (output) e.g. computational back-end without IO can be combined with different user interfaces Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 40 / 52

  68. Pure Functional Programming Side-effects Functions have no side-effect all communication is via the output cannot modify behaviour of other functions cannot do Input/Output (IO) directly cannot modify variables Pure functional languages forbid side-effects completely Avoiding side-effects is good practice easier to reuse code other applications often need same return value different side-effects (output) e.g. computational back-end without IO can be combined with different user interfaces Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 40 / 52

  69. Pure Functional Programming Side-effects Functions have no side-effect all communication is via the output cannot modify behaviour of other functions cannot do Input/Output (IO) directly cannot modify variables Pure functional languages forbid side-effects completely Avoiding side-effects is good practice easier to reuse code other applications often need same return value different side-effects (output) e.g. computational back-end without IO can be combined with different user interfaces Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 40 / 52

  70. Pure Functional Programming Side-effects Functions have no side-effect all communication is via the output cannot modify behaviour of other functions cannot do Input/Output (IO) directly cannot modify variables Pure functional languages forbid side-effects completely Avoiding side-effects is good practice easier to reuse code other applications often need same return value different side-effects (output) e.g. computational back-end without IO can be combined with different user interfaces Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 40 / 52

  71. Pure Functional Programming Side-effects An example function PseudoRandom() state := state * 17822228932 + 178324742 return state mod 256 You want a new pseudo-random number every time Side-effects is useful in this case Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 41 / 52

  72. Pure Functional Programming Side-effects An example function PseudoRandom() state := state * 17822228932 + 178324742 return state mod 256 You want a new pseudo-random number every time Side-effects is useful in this case Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 41 / 52

  73. Pure Functional Programming Other side-effects The most common side-effect is output This is often a bad side-effect You don’t always want the same output Some users will need the calculations without output Separation is useful Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 42 / 52

  74. Pure Functional Programming Imperative programming including Java Global state (memory) methods (functions) can change the state method behaviour can depend on state Different calls to f can give different output typical example: getchar (read keyboard input) one call removes a character from input buffer changes the value of the next call Functional principles can be used in imperative languages avoid side-effects when they are not necessary separate computations and IO Dr Hans Georg Schaathun Pure Functional Programming Spring 2010 43 / 52

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

Part I: Functional Programming A pure functional program consists of data, functions, and an

Part I: Functional Programming A pure functional program consists of data, functions, and an

Part I: Functional Programming A pure functional program consists of data, functions, and an expression which describes a result. Missing: variables, assignment, side-effects. A processor of a functional program is essentially a

833 views • 36 slides
61A Lecture 30 Wednesday, November 7 Functional Programming All functions are pure functions No

61A Lecture 30 Wednesday, November 7 Functional Programming All functions are pure functions No

61A Lecture 30 Wednesday, November 7 Functional Programming All functions are pure functions No assignment and no mutable data types (except for re-define) Name-value bindings are permanent Advantages of functional programming: The value

432 views • 13 slides
+ f(x) = Python Functional Programming Python Functional Programming Functional Programming by

+ f(x) = Python Functional Programming Python Functional Programming Functional Programming by

+ f(x) = Python Functional Programming Python Functional Programming Functional Programming by Wikipidia: Functional programming is a programming paradigm that treats computation as the evaluation of mathematical functions and avoids

754 views • 27 slides
The Return of Stream I/O @andrestaltz Cycle.js.org A functional and reactive JavaScript framework

The Return of Stream I/O @andrestaltz Cycle.js.org A functional and reactive JavaScript framework

The Return of Stream I/O @andrestaltz Cycle.js.org A functional and reactive JavaScript framework for cleaner code Haskell A pure functional programming language Haskell A pure functional programming language Logic Effects Haskell A

1.66k views • 117 slides
Q: A Functional Programming Language for Q: A Functional Programming Language Multimedia

Q: A Functional Programming Language for Q: A Functional Programming Language Multimedia

Q: A Functional Programming Language for Q: A Functional Programming Language Multimedia Applications Albert Grf Dept. of Music-Informatics Q: A Functional Programming Language Quick overview What? Why? The Library MIDI,

496 views • 12 slides
Futhark A data-parallel pure functional programming language compiling to GPU Troels Henriksen

Futhark A data-parallel pure functional programming language compiling to GPU Troels Henriksen

Futhark A data-parallel pure functional programming language compiling to GPU Troels Henriksen (athas@sigkill.dk) Computer Science University of Copenhagen 31. May 2016 ME PhD student at the Department of Computer Science at the University

1.04k views • 81 slides
Signal Processing in the Pure Programming Signal Processing in Pure Language Albert Grf Dept.

Signal Processing in the Pure Programming Signal Processing in Pure Language Albert Grf Dept.

Signal Processing in the Pure Programming Signal Processing in Pure Language Albert Grf Dept. of Music Informatics Full paper, slides, examples at: http://pure-lang.googlecode.com/svn/docs/ Pure, the programming language Signal

155 views • 14 slides
Functional Programming Pete Graham @petexgraham My Functional Programming Timeline Learned

Functional Programming Pete Graham @petexgraham My Functional Programming Timeline Learned

Functional Programming Pete Graham @petexgraham My Functional Programming Timeline Learned Haskell at University. Forgot it. Something strange happened... Functional Programming Renaissance 1. What is it? 2. Why learn Functional

559 views • 17 slides
61A Lecture 30 The value of an expression is independent of the order in which sub-expressions

61A Lecture 30 The value of an expression is independent of the order in which sub-expressions

Functional Programming All functions are pure functions No assignment and no mutable data types Name-value bindings are permanent Advantages of functional programming: 61A Lecture 30 The value of an expression is independent of the order in

425 views • 3 slides
Introduction to Functional Programming in Haskell 1 / 51 Outline Why learn functional

Introduction to Functional Programming in Haskell 1 / 51 Outline Why learn functional

Introduction to Functional Programming in Haskell 1 / 51 Outline Why learn functional programming? The essence of functional programming What is a function? Equational reasoning First-order vs. higher-order functions Lazy evaluation How to

794 views • 51 slides
Introduction to Functional Programming in Haskell 1 / 46 Outline Why learn functional

Introduction to Functional Programming in Haskell 1 / 46 Outline Why learn functional

Introduction to Functional Programming in Haskell 1 / 46 Outline Why learn functional programming? The essence of functional programming What is a function? Equational reasoning First-order vs. higher-order functions Lazy evaluation How to

778 views • 46 slides
Free Theorems about Monadic Code Janis Voigtl ander University of Bonn EWCE11 Functional

Free Theorems about Monadic Code Janis Voigtl ander University of Bonn EWCE11 Functional

Free Theorems about Monadic Code Janis Voigtl ander University of Bonn EWCE11 Functional Programming and Reasoning Goodies of (pure) FP: declarative abstraction/modularity referential transparency 1 Functional Programming

1.65k views • 149 slides
Introduction to Functional Programming in Python David Jones drj@ravenbrook.com Python and

Introduction to Functional Programming in Python David Jones drj@ravenbrook.com Python and

Introduction to Functional Programming in Python David Jones drj@ravenbrook.com Python and Functional Programming Beginner Journeyman Master Programming: Modes of Operation Functional Programming Object Oriented Programming Imperative

793 views • 24 slides
Functional Programming at Linspire Commercial Uses of Functional Programming Portland, Oregon

Functional Programming at Linspire Commercial Uses of Functional Programming Portland, Oregon

Functional Programming at Linspire Commercial Uses of Functional Programming Portland, Oregon Clifford Beshers Linspire, Inc. Linspire/Freespire Linux distribution for consumers No system manager Ultimately an appliance Preserve

340 views • 31 slides
Functional Programming with Isabelle/HOL e H O l L l e b a s = I

Functional Programming with Isabelle/HOL e H O l L l e b a s = I

Functional Programming with Isabelle/HOL e H O l L l e b a s = I Florian Haftmann Technische Universit at M unchen January 2009 Overview Viewing Isabelle / HOL as a functional programming language: 1.

464 views • 34 slides
functional thinking applying the philosophy of functional programming to system design &amp;

functional thinking applying the philosophy of functional programming to system design &amp;

functional thinking applying the philosophy of functional programming to system design &amp; architecture Jed Wesley-Smith @jedws please, ask questions functional programming has many bene fj ts: better program reasonability, composition,

787 views • 67 slides
Functors, Applicatives, and Monads Practice Curtis Millar CSE, UNSW (and Data61) 15 July 2020 1

Functors, Applicatives, and Monads Practice Curtis Millar CSE, UNSW (and Data61) 15 July 2020 1

Exercise 4 State &amp; IO Higher Kinds More Examples Administrivia Software System Design and Implementation Functors, Applicatives, and Monads Practice Curtis Millar CSE, UNSW (and Data61) 15 July 2020 1 Exercise 4 State &amp; IO

433 views • 30 slides
On the Interval Property Level and Gorenstein in algebra and combinatorics algebras Pure O

On the Interval Property Level and Gorenstein in algebra and combinatorics algebras Pure O

The Interval Property On the Interval Property Level and Gorenstein in algebra and combinatorics algebras Pure O -sequences Pure FABRIZIO ZANELLO f -vectors (MIT and Michigan Tech) Differential posets AMS Meeting of Lincoln, NE October

956 views • 59 slides
Multiagent Evaluation under Incomplete Information Mark Rowland * , Shayegan Omidshafiei * , Karl

Multiagent Evaluation under Incomplete Information Mark Rowland * , Shayegan Omidshafiei * , Karl

Multiagent Evaluation under Incomplete Information Mark Rowland * , Shayegan Omidshafiei * , Karl Tuyls, Julien Prolat, Michal Valko, Georgios Piliouras , Rmi Munos * Equal contributors Singapore University of Technology and Design

240 views • 11 slides
Inf2D 07: Effective Propositional Inference Valerio Restocchi School of Informatics, University

Inf2D 07: Effective Propositional Inference Valerio Restocchi School of Informatics, University

Inf2D 07: Effective Propositional Inference Valerio Restocchi School of Informatics, University of Edinburgh 28/01/20 Slide Credits: Jacques Fleuriot, Michael Rovatsos, Michael Herrmann, Vaishak Belle Outline Two families of efficient

1.01k views • 23 slides
Automatically proving linearizability Viktor Vafeiadis University of Cambridge CAV 2010

Automatically proving linearizability Viktor Vafeiadis University of Cambridge CAV 2010

Automatically proving linearizability Viktor Vafeiadis University of Cambridge CAV 2010 M&amp;S non-blocking queue head tail null X 1 2 3 4 typedef struct Node_s *Node; struct Queue_s *Q; struct Node_s { init() { int val; n = new

379 views • 25 slides
Stable finiteness and pure infiniteness of the C -algebras of higher-rank graphs Astrid an

Stable finiteness and pure infiniteness of the C -algebras of higher-rank graphs Astrid an

Stable finiteness and pure infiniteness of the C -algebras of higher-rank graphs Astrid an Huef University of Houston, July 31 2017 Overview Let E be a directed graph such that the graph C -algebra C ( E ) is simple ( E is

429 views • 19 slides
From Object Fields to Local Variables: a Practical Approach to Field-Sensitive Analysis Elvira

From Object Fields to Local Variables: a Practical Approach to Field-Sensitive Analysis Elvira

From Object Fields to Local Variables: a Practical Approach to Field-Sensitive Analysis Elvira Albert (1) , Puri Arenas (1) , Samir Genaim (1) , an Puebla (2) and Diana Ram rez (2) Germ (1) Complutense University of Madrid (2) Technical

1.27k views • 77 slides
A Discrete Strategy Improvement Algorithm for Solving Parity Games Jens V oge Marcin

A Discrete Strategy Improvement Algorithm for Solving Parity Games Jens V oge Marcin

A Discrete Strategy Improvement Algorithm for Solving Parity Games Jens V oge Marcin Jurdzi nski Lehrstuhl f ur Informatik VII BRICS RWTH Aachen University of Aarhus Germany Denmark Chicago, USA, 19 July 2000 1 Complexity of

295 views • 11 slides

More recommend