types of programming languages
play

TYPES OF PROGRAMMING LANGUAGES PRINCIPLES OF PROGRAMMING LANGUAGES - PowerPoint PPT Presentation

Nov 29, 2022 •208 likes •1.59k views

TYPES OF PROGRAMMING LANGUAGES PRINCIPLES OF PROGRAMMING LANGUAGES Norbert Zeh Winter 2019 Dalhousie University 1/30 REASONS TO CHOOSE A PARTICULAR PROGRAMMING LANGUAGE Easy to express complex ideas Easy to control exactly how the

  1. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  2. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  3. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  4. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  5. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  6. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  7. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  8. TYPES OF PROGRAMMING LANGUAGES Scheme Declarative Functional Object-oriented Imperative Logic Concatenative Factor Forth Postscript Hilog Prolog Haskell Scala C ML Lisp Swift Objective C Java Ruby Python C++ Fortran Ada Modula Pascal 5/30

  9. THE LANGUAGES I USE • When I need to write a Haskell • When I’d rather teach you Scheme • Never Java • When I’m told to use Java Scala prototype quickly Python Rust or C++ • When I want to solve puzzles Prolog write elegant code that I trust • When I want to have fun and Haskell • When I feel nostalgic C • When I need performance 6/30

  10. • Focus on telling the • Focus on telling the computer what IMPERATIVE VS DECLARATIVE PROGRAMMING optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: Imperative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30

  11. • Focus on telling the computer what IMPERATIVE VS DECLARATIVE PROGRAMMING optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: Imperative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the

  12. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  13. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  14. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  15. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  16. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  17. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  18. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  19. IMPERATIVE VS DECLARATIVE PROGRAMMING Imperative programming: optimize/parallelize • Easier to analyze/automatically penalties • Can come with performance in run-time system • Need to include evaluation engine • More high-level, elegant, expressive to do, not how to do it Declarative programming: • Side effects • Return values • Functions called for automatically optimize • Difficult to analyze/ • Close to the machine steps to execute computer exactly which 7/30 • Focus on telling the • Focus on telling the computer what

  20. SIDE EFFECTS • Variable updates, I/O (disk, screen, keyboard, network, …) … are evil: • Source of 90% of all software bugs … are the only reason we compute at all: • Taking input and communicating results requires side effects. 8/30

  21. SIDE EFFECTS • Variable updates, I/O (disk, screen, keyboard, network, …) … are evil: • Source of 90% of all software bugs … are the only reason we compute at all: • Taking input and communicating results requires side effects. 8/30

  22. SIDE EFFECTS • Variable updates, I/O (disk, screen, keyboard, network, …) … are evil: • Source of 90% of all software bugs … are the only reason we compute at all: • Taking input and communicating results requires side effects. 8/30

  23. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  24. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  25. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  26. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  27. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  28. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  29. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than easy to parallelize • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined 9/30

  30. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than 9/30 • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined → easy to parallelize

  31. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than 9/30 • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined → easy to parallelize

  32. FUNCTIONAL PROGRAMMING Cons: functional counterparts efficient than their purely structures are inherently more • Some imperative data well-designed imperative code • Can be less efficient than 9/30 • Functions have no side effects • No specified execution order • Easier to analyze/optimize Pros: • Can express imperative computations elegantly! • Functions are first-class objects • Variables are immutable once defined → easy to parallelize

  33. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  34. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  35. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  36. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  37. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  38. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  39. LOGIC PROGRAMMING • In theory, no need to worry • Obtain efficient programs • Avoid infinite loops in deduction execution details enough to • In practice, need to understand Cons: about execution details at all functional programming General program structure: • Even higher abstraction than Pros: • Engine to perform the deduction process efficiently Runtime system: • Execution driven by queries whether certain facts are true • Rules for deducing new facts from known facts • Database of facts, represented as logical predicates 10/30

  40. INTERMISSION: SCHEME AND PROLOG TUTORIALS 11/30

  41. AN EXAMPLE WHERE FUNCTIONAL PROGRAMMING SHINES: MERGE SORT (1) merge_sort(mid, end); } merge(left, right, begin); right(mid, end); std::vector<std::iterator_traits<It>::value_type> left(begin, mid); std::vector<std::iterator_traits<It>::value_type> merge_sort(begin, mid); C++: auto mid = begin + n / 2; return; if (n < 2) auto n = end - begin; void merge_sort(const It &begin, const It &end) { template <typename It> 12/30

  42. AN EXAMPLE WHERE FUNCTIONAL PROGRAMMING SHINES: MERGE SORT (2) else } *out++ = *r++; while (r != right.end()) *out++ = *l++; while (l != left.end()) } *out++ = *l++; *out++ = *r++; template <typename It> if (*r < *l) while (l != left.end() && r != right.end()) { auto l = left.begin(), r = right.begin(); It out) { const std::vector<std::iterator_traits<It>::value_type> &right, const std::vector<std::iterator_traits<It>::value_type> &left, void merge( 13/30

  43. AN EXAMPLE WHERE FUNCTIONAL PROGRAMMING SHINES: MERGE SORT (3) merge [] | otherwise = l : merge ls' rs rs' = r : merge ls merge ls@(l:ls') rs@(r:rs') | r < l = ls [] merge ls = rs rs merge :: Ord t => [t] -> [t] -> [t] Haskell: (ls, rs) = splitAt (n `div` 2) xs = length xs where n = merge (mergeSort ls) (mergeSort rs) mergeSort xs mergeSort [x] = [x] = [] mergeSort [] mergeSort :: Ord t => [t] -> [t] 14/30

  44. AN EXAMPLE WHERE FUNCTIONAL PROGRAMMING SHINES: MERGE SORT (4) Prolog: list_sorted([], []). list_sorted([X], [X]). list_sorted(List, Sorted) :- list_left_right(List, Left, Right), list_sorted(Left, LeftSorted), list_sorted(Right, RightSorted), merged_left_right(Sorted, LeftSorted, RightSorted). merged_left_right(Left, Left, []). merged_left_right([R|Right], [], [R|Right]). merged_left_right([L|Merged], [L|Left], [R|Right]) :- L #=< R, merged_left_right(Merged, Left, [R|Right]). merged_left_right([R|Merged], [L|Left], [R|Right]) :- R #< L, merged_left_right(Merged, [L|Left], Right). 15/30

  45. AN EXAMPLE WHERE FUNCTIONAL PROGRAMMING SHINES: MERGE SORT (5) list_left_right(List, Left, Right) :- phrase(parse_half(List, Left), List, Right). parse_half([], []) --> []. parse_half([_], []) --> []. parse_half([_,_|List], [L|Left]) --> [L], parse_half(List, Left). 16/30

  46. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  47. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 3 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 4 1 5 6 0 4 2 6 1 3 5 0 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  48. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 3 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 4 1 5 6 0 4 2 6 1 3 5 0 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  49. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 3 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 4 1 5 6 0 4 2 6 1 3 5 0 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  50. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 3 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 4 1 5 6 0 4 2 6 1 3 5 0 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  51. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  52. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  53. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  54. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  55. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  56. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  57. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  58. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  59. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: 4 0 2 1 3 0 4 2 1 3 0 2 2 1 3 5 1 2 3 4 5 6 Input: Output: 1 0 DYNAMIC DATA STRUCTURES (1) 1 indicating, for each element, after which element it is to be inserted. Example: 0 0 1 0 3 2 1 2 3 4 5 6 0 4 2 6 1 3 5 0 17/30 Problem: Build a permutation of the integers { 0 , 1 , . . . , n − 1 } specified by

  60. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  61. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  62. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  63. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  64. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  65. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  66. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  67. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  68. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  69. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  70. AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: } 5 3 1 6 2 4 0 return std::vector<int>(seq.begin(), seq.end()); DYNAMIC DATA STRUCTURES (2) list_nodes[i] = seq.insert(next(list_nodes[ref[i]]), i); for (int i = 1; i < n; ++i) list_nodes[0] = seq.insert(seq.end(), 0); std::vector<std::list<int>::iterator> list_nodes(n); std::list<int> seq; int n = ref.size() + 1; std::vector<int> dynamic_permute(const std::vector<int> &refs) { C++: Linear time 18/30

  71. This makes standard pointer-based data structures difficult/impossible to AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: DYNAMIC DATA STRUCTURES (3) Doing this without mutation: 0 3 1 2 0 1 2 When “updating” any node in a functional data structure, all nodes with a path of pointers to it need to be replaced too. implement functionally. 19/30

  72. This makes standard pointer-based data structures difficult/impossible to AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: DYNAMIC DATA STRUCTURES (3) Doing this without mutation: 0 3 1 2 0 1 2 When “updating” any node in a functional data structure, all nodes with a path of pointers to it need to be replaced too. implement functionally. 19/30

  73. This makes standard pointer-based data structures difficult/impossible to AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: DYNAMIC DATA STRUCTURES (3) Doing this without mutation: 0 3 1 2 0 1 2 When “updating” any node in a functional data structure, all nodes with a path of pointers to it need to be replaced too. implement functionally. 19/30

  74. This makes standard pointer-based data structures difficult/impossible to AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: DYNAMIC DATA STRUCTURES (3) Doing this without mutation: 0 3 1 2 0 1 2 When “updating” any node in a functional data structure, all nodes with a path of pointers to it need to be replaced too. implement functionally. 19/30

  75. This makes standard pointer-based data structures difficult/impossible to AN EXAMPLE WHERE IMPERATIVE PROGRAMMING SHINES: DYNAMIC DATA STRUCTURES (3) Doing this without mutation: 0 3 1 2 0 1 2 When “updating” any node in a functional data structure, all nodes with a path of pointers to it need to be replaced too. implement functionally. 19/30

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

Subtyping Thomas Wies wies@mpi-sb.mpg.de Seminar: Types and Programming Languages, WS 02/03

Subtyping Thomas Wies wies@mpi-sb.mpg.de Seminar: Types and Programming Languages, WS 02/03

Subtyping Thomas Wies wies@mpi-sb.mpg.de Seminar: Types and Programming Languages, WS 02/03 Pierce, ch. 15-18 Types and Programming Languages 1 O VERVIEW The subtype relation Typechecking Extensions: references, casts Case

635 views • 42 slides
CSEP505: Programming Languages Lecture 8: Types Wrap-Up; Object-Oriented Programming Dan

CSEP505: Programming Languages Lecture 8: Types Wrap-Up; Object-Oriented Programming Dan

CSEP505: Programming Languages Lecture 8: Types Wrap-Up; Object-Oriented Programming Dan Grossman Spring 2006 Todays plan Three last things about types 1. Type inference (ML-style) 2. Bounded polymorphism (subtyping &amp; forall) 3.

864 views • 69 slides
Data Types COS 301 - Programming Languages Fall 2018 UMAINE CIS COS 301 Programming

Data Types COS 301 - Programming Languages Fall 2018 UMAINE CIS COS 301 Programming

Data Types COS 301 - Programming Languages Fall 2018 UMAINE CIS COS 301 Programming Languages Types Type collection of values + operations on them Ex: integers: values: , -2, -1, 0, 1, 2, operations: +, -, *, /,

987 views • 57 slides
CS 360 Programming Languages Day 6 Today Type systems Rules for how types are

CS 360 Programming Languages Day 6 Today Type systems Rules for how types are

CS 360 Programming Languages Day 6 Today Type systems Rules for how types are determined in a language. Side effects ...and why they are not used in functional programming. Tail recursion Special speed-up built

892 views • 40 slides
15-814 Types and Programming Languages Introduction and Overview Frank Pfenning Department of

15-814 Types and Programming Languages Introduction and Overview Frank Pfenning Department of

15-814 Types and Programming Languages Introduction and Overview Frank Pfenning Department of Computer Science Carnegie Mellon University Tue Sep 1, 2020 1 / 6 Outline 1 Introductions 2 Course Details 3 Why and How Do We Study Languages 4

166 views • 6 slides
Programming Languages Third Edition Chapter 8 Data Types Objectives Understand data types

Programming Languages Third Edition Chapter 8 Data Types Objectives Understand data types

Programming Languages Third Edition Chapter 8 Data Types Objectives Understand data types and type information Understand simple types Understand type constructors Be able to distinguish type nomenclature in sample languages

1.19k views • 114 slides
CSC 1800 Organization of Programming Languages Data Types 1 Inspiration for Language Elements

CSC 1800 Organization of Programming Languages Data Types 1 Inspiration for Language Elements

CSC 1800 Organization of Programming Languages Data Types 1 Inspiration for Language Elements Imperative languages are abstractions of von Neumann architecture Memory Processor Variables characterized by attributes To

670 views • 32 slides
Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages

Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages

Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages CS251 Programming Languages Fall 2016, Lyn Turbak Department of Computer Science Wellesley College Discussion: P rogramming L anguages Your

496 views • 30 slides
Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages

Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages

Big Ideas for CS 251 Theory of Programming Languages Principles of Programming Languages CS251&amp;Programming&amp;Languages&amp; Spring&amp;2016,&amp;Lyn&amp;Turbak&amp; ! Department!of!Computer!Science! Wellesley!College! Discussion:

933 views • 27 slides
Programming Languages Chapter One Modern Programming Languages, 2nd ed. 1 Outline What

Programming Languages Chapter One Modern Programming Languages, 2nd ed. 1 Outline What

Programming Languages Chapter One Modern Programming Languages, 2nd ed. 1 Outline What makes programming languages an interesting subject? The amazing variety The odd controversies The intriguing evolution The connection to

712 views • 39 slides
CS4450: Principles of Programming Languages Imperative features; reference types Dr William

CS4450: Principles of Programming Languages Imperative features; reference types Dr William

CS4450: Principles of Programming Languages Imperative features; reference types Dr William Harrison Today: Imperative programming Imperative programming l i.e., programming with ; := l Case Study: imperative programming in ML

441 views • 29 slides
Advances in Programming Languages APL7: Polymorphism from Types to Kinds and Beyond Ian Stark

Advances in Programming Languages APL7: Polymorphism from Types to Kinds and Beyond Ian Stark

Advances in Programming Languages APL7: Polymorphism from Types to Kinds and Beyond Ian Stark School of Informatics The University of Edinburgh Tuesday 12 October Semester 1 Week 4 N I V E U R S E I H T T Y O H F G R E

667 views • 30 slides
Recollecting Haskell, Part IV User Defined Types CIS 352 Programming Languages January 22, 2019

Recollecting Haskell, Part IV User Defined Types CIS 352 Programming Languages January 22, 2019

Recollecting Haskell, Part IV User Defined Types CIS 352 Programming Languages January 22, 2019 CIS 352 Algebraic Types 1 / 23 Enumerated Types, 1 Recall type synonyms: type Point = (Float,Float) -- A shorthand name for a type You also

418 views • 23 slides
Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages

Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages

Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages Topics Fundamentals of Subprograms Design Issues Parameter-Passing Methods Function Parameters Local Referencing Environments

538 views • 28 slides
Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages

Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages

Subprograms COS 301 Programming Languages UMAINE CIS COS 301 Programming Languages Topics Fundamentals of Subprograms Design Issues Parameter-Passing Methods Function Parameters Local Referencing Environments

1.41k views • 110 slides
3 PLC Programming The long march to IEC 61131 PLC industry needs aggreement on Data types

3 PLC Programming The long march to IEC 61131 PLC industry needs aggreement on Data types

EPFL, Spring 2017 3 PLC Programming The long march to IEC 61131 PLC industry needs aggreement on Data types (operations may only be executed on appropriate types) Programming languages Software structure (program organization units

1.65k views • 68 slides
Compiler Development (CMPSC 401) Janyl Jumadinova January 17, 2018 Janyl Jumadinova Compiler

Compiler Development (CMPSC 401) Janyl Jumadinova January 17, 2018 Janyl Jumadinova Compiler

Compiler Development (CMPSC 401) Janyl Jumadinova January 17, 2018 Janyl Jumadinova Compiler Development (CMPSC 401) January 17, 2018 1 / 34 What is a compiler? Janyl Jumadinova Compiler Development (CMPSC 401) January 17, 2018 2 / 34

954 views • 59 slides
Reading This Week Review: High-Level Language Review: Java Does Both! CPSC 111, Intro to

Reading This Week Review: High-Level Language Review: Java Does Both! CPSC 111, Intro to

University of British Columbia Reading This Week Review: High-Level Language Review: Java Does Both! CPSC 111, Intro to Computation 2009W2: Jan-Apr 2010 Chap 1: 1.3-1.8 Must be translated into machine language so the computer Your

375 views • 4 slides
rs r tr st

rs r tr st

rs r tr st tr sst s r rs t r s

285 views • 25 slides
Integrating Productivity-Oriented Programming Languages with High-Performance Data Structures

Integrating Productivity-Oriented Programming Languages with High-Performance Data Structures

Integrating Productivity-Oriented Programming Languages with High-Performance Data Structures James Fairbanks Rohit Varkey Thankachan, Eric Hein, Brian Swenson Georgia Tech Research Institute September 13 2017 1 / 20 Graph Analysis

475 views • 21 slides
Disclosures Author of chapters in UpToDate Definition of osteoporosis NIH Conference A

Disclosures Author of chapters in UpToDate Definition of osteoporosis NIH Conference A

Bad to the Bone 5-3-19 Alaska ACP Brad Anawalt, MD Vice Chair and Professor of Medicine University of Washington banawalt@medicine.washington.edu Disclosures Author of chapters in UpToDate Definition of osteoporosis NIH

204 views • 16 slides
2016 Agenda Welcome......Rob Brooks 2

2016 Agenda Welcome......Rob Brooks 2

Introductory Meeting September 22, 2016 2016 Agenda Welcome......Rob Brooks 2 Prayer/Pledge..Jack Steed

416 views • 16 slides
Integrating Legacy User Authentication with HIP Jani Hautakorpi (Jani.Hautakorpi@hut.fi) 1 / 11

Integrating Legacy User Authentication with HIP Jani Hautakorpi (Jani.Hautakorpi@hut.fi) 1 / 11

T-110.557 Research Seminar on Telecommunications Software Integrating Legacy User Authentication with HIP Jani Hautakorpi (Jani.Hautakorpi@hut.fi) 1 / 11 Contents HIP base exchange Selected legacy user authentication mechanisms:

241 views • 11 slides
Intensity Values Stephen Bailey Instructor DataCamp Biomedical Image Analysis in Python Pixels

Intensity Values Stephen Bailey Instructor DataCamp Biomedical Image Analysis in Python Pixels

DataCamp Biomedical Image Analysis in Python BIOMEDICAL IMAGE ANALYSIS IN PYTHON Intensity Values Stephen Bailey Instructor DataCamp Biomedical Image Analysis in Python Pixels and voxels Pixels are 2D picture elements Voxels are 3D volume

509 views • 33 slides

More recommend