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

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

671 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

713 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
Chapter 2 Early History: low level languages The 1950s: first programming languages History of

Chapter 2 Early History: low level languages The 1950s: first programming languages History of

Topics Chapter 2 Early History: low level languages The 1950s: first programming languages History of Programming The 1960s: an explosion in programming languages Languages The 1970s: back to simplicity Functional and logic programming

582 views • 8 slides
CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013

CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013

CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013 Faculty of Computer Science Dalhousie University 1 / 56 What is a Type System? A type system is a mechanism for defining types and associating them

705 views • 56 slides
CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013

CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013

CSCI 3136 Principles of Programming Languages Data Types and Memory Management Summer 2013 Faculty of Computer Science Dalhousie University 1 / 21 What is a Type System? A type system is a mechanism for defining types and associating them

326 views • 21 slides
CSEP505: Programming Languages Lecture 5: continuations, types Dan Grossman Spring 2006

CSEP505: Programming Languages Lecture 5: continuations, types Dan Grossman Spring 2006

CSEP505: Programming Languages Lecture 5: continuations, types Dan Grossman Spring 2006 Remember our symbol-pile Expressions: e ::= x | x . e | e e Values: v ::= x . e e1 ! x . e3 e2 ! v2 e3 { v2 /x} ! v

789 views • 66 slides
Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019

Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019

Dynamically Typed Programming Languages Part 2: Dynamic PCF Jim Royer CIS 352 April 16, 2019 Reference Practical Foundations for Programming Languages, 1/e, Part VI: Dynamic Types , by Robert Harper, Cambridge University Press, 2013,

107 views • 9 slides
Existential Types for Imperative Languages Dan Grossman Cornell University Eleventh European

Existential Types for Imperative Languages Dan Grossman Cornell University Eleventh European

Existential Types for Imperative Languages Dan Grossman Cornell University Eleventh European Symposium on Programming April 2002 Designing safe languages To design a strong-typed language: 1. Draw on acquired knowledge of well- behaved

410 views • 29 slides
Advanced #1: Programming Languages SAMS SENIOR CS TRACK Learning Goals Understand the different

Advanced #1: Programming Languages SAMS SENIOR CS TRACK Learning Goals Understand the different

Advanced #1: Programming Languages SAMS SENIOR CS TRACK Learning Goals Understand the different types of imperative and declarative programming paradigms Recognize other variations in programming language design have strengths and weaknesses

412 views • 17 slides
Programming language shapes Programming thought programming languages are not merely

Programming language shapes Programming thought programming languages are not merely

CMPS 112: Spring 2019 Comparative Programming Languages Lecture 1: Course Overview. Owen Arden UC Santa Cruz A Programming Language Two variables L1: x++; x , y y--; Three operations (y=0)?L2:L1 x++ L2:

476 views • 18 slides

More recommend