subroutines and control abstraction
play

SUBROUTINES AND CONTROL ABSTRACTION PRINCIPLES OF PROGRAMMING - PowerPoint PPT Presentation

Apr 07, 2023 •38 likes •1.11k views

SUBROUTINES AND CONTROL ABSTRACTION PRINCIPLES OF PROGRAMMING LANGUAGES Norbert Zeh Winter 2018 Dalhousie University 1/47 ABSTRACTIONS AS PROGRAM BUILDING BLOCKS Programming is about building abstractions. Subroutines are the main method to

  1. • in out parameters: Call by reference or call by value/return EXAMPLES OF PARAMETER PASSING MODES (2) Smalltalk, Lisp, Clu, ML: • Reference model of variables identity of the object cannot change. Ada: • in parameters: Call by value • out parameters: “Call by result” C++: • Same as C but with the addition of reference parameters: void swap(int &a, int &b) { int t = a; a = b; b = t; } • References can be declared const : efficiency of call by reference and safety of call by value 12/47 ⇒ Call by sharing: Object can be altered, just as with call by reference but the

  2. EXAMPLES OF PARAMETER PASSING MODES (2) Smalltalk, Lisp, Clu, ML: • Reference model of variables identity of the object cannot change. Ada: • in parameters: Call by value • out parameters: “Call by result” C++: • Same as C but with the addition of reference parameters: void swap(int &a, int &b) { int t = a; a = b; b = t; } • References can be declared const : efficiency of call by reference and safety of call by value 12/47 ⇒ Call by sharing: Object can be altered, just as with call by reference but the • in out parameters: Call by reference or call by value/return

  3. EXAMPLES OF PARAMETER PASSING MODES (2) Smalltalk, Lisp, Clu, ML: • Reference model of variables identity of the object cannot change. Ada: • in parameters: Call by value • out parameters: “Call by result” C++: • Same as C but with the addition of reference parameters: void swap(int &a, int &b) { int t = a; a = b; b = t; } • References can be declared const : efficiency of call by reference and safety of call by value 12/47 ⇒ Call by sharing: Object can be altered, just as with call by reference but the • in out parameters: Call by reference or call by value/return

  4. EXAMPLES OF PARAMETER PASSING MODES (3) Java, Python: • Call by value for primitive types • Call by sharing for compound types (objects) C#: • Call by value/sharing is the default • ref and out keywords to force call by reference • Distinction between call by value and call by sharing made at data type level: • struct types are values. • class types are references. 13/47

  5. EXAMPLES OF PARAMETER PASSING MODES (3) Java, Python: • Call by value for primitive types • Call by sharing for compound types (objects) C#: • Call by value/sharing is the default • ref and out keywords to force call by reference • Distinction between call by value and call by sharing made at data type level: • struct types are values. • class types are references. 13/47

  6. READ-ONLY PARAMETERS A common practice in Pascal: • Large values are passed by reference for efficiency reasons • High potential for bugs Read-only parameters address this problem: • Efficiency of call by reference • Safety of call by value Modula 3: readonly parameters ANSI C, C++: const parameters When using call by value, declaring a parameter readonly or const is pointless. 14/47

  7. READ-ONLY PARAMETERS A common practice in Pascal: • Large values are passed by reference for efficiency reasons • High potential for bugs Read-only parameters address this problem: • Efficiency of call by reference • Safety of call by value Modula 3: readonly parameters ANSI C, C++: const parameters When using call by value, declaring a parameter readonly or const is pointless. 14/47

  8. READ-ONLY PARAMETERS A common practice in Pascal: • Large values are passed by reference for efficiency reasons • High potential for bugs Read-only parameters address this problem: • Efficiency of call by reference • Safety of call by value Modula 3: readonly parameters ANSI C, C++: const parameters When using call by value, declaring a parameter readonly or const is pointless. 14/47

  9. READ-ONLY PARAMETERS A common practice in Pascal: • Large values are passed by reference for efficiency reasons • High potential for bugs Read-only parameters address this problem: • Efficiency of call by reference • Safety of call by value Modula 3: readonly parameters ANSI C, C++: const parameters When using call by value, declaring a parameter readonly or const is pointless. 14/47

  10. SOME USES OF CONST IN C++ Constant definition: const int buffersize = 512; Read-only function parameter: void f(const int &i) { ... } Immutable reference returned by a function (e.g., container interfaces) : const string &f() { ... } Object method that cannot change the object (the only type of method that can be invoked on a const object) : int A::f(int i, string s) const { ... } 15/47

  11. SOME USES OF CONST IN C++ Constant definition: const int buffersize = 512; Read-only function parameter: void f(const int &i) { ... } Immutable reference returned by a function (e.g., container interfaces) : const string &f() { ... } Object method that cannot change the object (the only type of method that can be invoked on a const object) : int A::f(int i, string s) const { ... } 15/47

  12. SOME USES OF CONST IN C++ Constant definition: const int buffersize = 512; Read-only function parameter: void f(const int &i) { ... } Immutable reference returned by a function (e.g., container interfaces) : const string &f() { ... } Object method that cannot change the object (the only type of method that can be invoked on a const object) : int A::f(int i, string s) const { ... } 15/47

  13. SOME USES OF CONST IN C++ Constant definition: const int buffersize = 512; Read-only function parameter: void f(const int &i) { ... } Immutable reference returned by a function (e.g., container interfaces) : const string &f() { ... } Object method that cannot change the object (the only type of method that can be invoked on a const object) : int A::f(int i, string s) const { ... } 15/47

  14. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 16/47

  15. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 16/47

  16. SUBROUTINE CLOSURES AS PARAMETERS Function as parameters and function return values require the passing of closures. Languages that support this: • Pascal • Ada 95 (not Ada 83) • All functional programming languages Restricted passing of functions in C/C++ and FORTRAN: • Functions are not allowed to nest (or not significantly in FORTRAN) • No need for closures • Pointers to subroutines suffice 17/47

  17. SUBROUTINE CLOSURES AS PARAMETERS Function as parameters and function return values require the passing of closures. Languages that support this: • Pascal • Ada 95 (not Ada 83) • All functional programming languages Restricted passing of functions in C/C++ and FORTRAN: • Functions are not allowed to nest (or not significantly in FORTRAN) • No need for closures • Pointers to subroutines suffice 17/47

  18. SUBROUTINE CLOSURES AS PARAMETERS Function as parameters and function return values require the passing of closures. Languages that support this: • Pascal • Ada 95 (not Ada 83) • All functional programming languages Restricted passing of functions in C/C++ and FORTRAN: • Functions are not allowed to nest (or not significantly in FORTRAN) • No need for closures • Pointers to subroutines suffice 17/47

  19. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 18/47

  20. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 18/47

  21. DEFAULT (OPTIONAL) PARAMETERS Default (optional) parameters need not be specified by the caller. If not specified, they take default values. Ada: procedure put(item : in integer; width : int field := 10); C++: void put(int item, int width = 10) { ... } Implementation is trivial. How? 19/47

  22. DEFAULT (OPTIONAL) PARAMETERS Default (optional) parameters need not be specified by the caller. If not specified, they take default values. Ada: procedure put(item : in integer; width : int field := 10); C++: void put(int item, int width = 10) { ... } Implementation is trivial. How? 19/47

  23. NAMED (KEYWORD) PARAMETERS Named (keyword) parameters need not appear in a fixed order. • Good for documenting the purpose of parameters in a call. • Necessary to utilize the full power of default parameters. Ada: format_page(columns => 2, width => 4, font => Helvetica); Implementation is once again trivial. How? 20/47

  24. NAMED (KEYWORD) PARAMETERS Named (keyword) parameters need not appear in a fixed order. • Good for documenting the purpose of parameters in a call. • Necessary to utilize the full power of default parameters. Ada: format_page(columns => 2, width => 4, font => Helvetica); Implementation is once again trivial. How? 20/47

  25. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 21/47

  26. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 21/47

  27. VARIADIC SUBROUTINES (VARIABLE NUMBER OF ARGUMENTS) C/C++/Python allow variable numbers of arguments: #include <stdarg.h> int printf1(char *format, ...) { va_list args; va_start(args, format); char c = va_arg(args, char); ... va_end(args); } Java and C# provide similar facilities, in a typesafe but more restrictive manner. 22/47

  28. VARIADIC SUBROUTINES (VARIABLE NUMBER OF ARGUMENTS) C/C++/Python allow variable numbers of arguments: #include <stdarg.h> int printf1(char *format, ...) { va_list args; va_start(args, format); char c = va_arg(args, char); ... va_end(args); } Java and C# provide similar facilities, in a typesafe but more restrictive manner. 22/47

  29. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 23/47

  30. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 23/47

  31. GENERIC SUBROUTINES AND MODULES Standard subroutines allow the same code to be applied to many different values. There is a trade-off involved in balancing the generality of the framework with type safety. 24/47 Generic subroutines can be applied to many different types.

  32. GENERIC SUBROUTINES AND MODULES Standard subroutines allow the same code to be applied to many different values. There is a trade-off involved in balancing the generality of the framework with type safety. 24/47 Generic subroutines can be applied to many different types.

  33. GENERIC SUBROUTINES: RUNTIME TYPE CHECKS Examples: Lisp, Scheme, Python, Ruby (defun merge (a b) (cond ((null? a) b) ((null? b) a) ((< (car a) (car b)) (cons (car a) (merge (cdr a) b))) (t (cons (car b) (merge a (cdr b)))))) 25/47

  34. GENERIC SUBROUTINES: COMPILE-TIME TYPE CHECKS UPON INSTANTIATION Example: C++ templates class A { int f(); }; class B { // No method f }; template <class T> class C { T data; int g() { return data.f(); } }; C<A> a; // OK C<B> b; // Error 26/47

  35. GENERIC SUBROUTINES: COMPILE-TIME TYPE CHECKS UPON DECLARATION Examples: • Java interfaces • Haskell type classes public static <T extends Comparable<T>> void sort(T A[]) { ... if (A[i].compareTo(A[j]) >= 0) { ... } ... } Integer[] myArray = new Integer[50]; sort(myArray); 27/47

  36. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 28/47

  37. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 28/47

  38. EXCEPTION HANDLING Exception Unexpected or abnormal condition arising during program execution Exceptions may be generated automatically in response to runtime errors or raised explicitly in the program. Typical semantics of exception handling • Exception handler lexically bound to a block of code. • An exception raised in the block replaces the remaining code in the block with the code of the corresponding exception handler. • If there is no matching handler, the subroutine exits anda handler is looked for in the calling subroutine. Some (older) languages deviate from this. 29/47

  39. EXCEPTION HANDLING Exception Unexpected or abnormal condition arising during program execution Exceptions may be generated automatically in response to runtime errors or raised explicitly in the program. Typical semantics of exception handling • Exception handler lexically bound to a block of code. • An exception raised in the block replaces the remaining code in the block with the code of the corresponding exception handler. • If there is no matching handler, the subroutine exits anda handler is looked for in the calling subroutine. Some (older) languages deviate from this. 29/47

  40. EXCEPTION HANDLING Exception Unexpected or abnormal condition arising during program execution Exceptions may be generated automatically in response to runtime errors or raised explicitly in the program. Typical semantics of exception handling • Exception handler lexically bound to a block of code. • An exception raised in the block replaces the remaining code in the block with the code of the corresponding exception handler. • If there is no matching handler, the subroutine exits anda handler is looked for in the calling subroutine. Some (older) languages deviate from this. 29/47

  41. EXCEPTION HANDLING Exception Unexpected or abnormal condition arising during program execution Exceptions may be generated automatically in response to runtime errors or raised explicitly in the program. Typical semantics of exception handling • Exception handler lexically bound to a block of code. • An exception raised in the block replaces the remaining code in the block with the code of the corresponding exception handler. • If there is no matching handler, the subroutine exits anda handler is looked for in the calling subroutine. Some (older) languages deviate from this. 29/47

  42. USE OF EXCEPTION HANDLERS • Perform operations necessary to recover from the exception. • Terminate the program gracefully, with a meaningful error message. • Clean up resources allocated in the protected block before re-raising the exception. 30/47

  43. EXCEPTION SUPPORT IN PROGRAMMING LANGUAGES (1) Representing exceptions: • Built-in exception type • Object derived from an exception class • Any kind of data can be raised as an exception Raising exceptions: • Automatically by the run-time system as a result of an abnormal condition (e.g., division by zero) • throw / raise statement to raise exceptions manually 31/47

  44. EXCEPTION SUPPORT IN PROGRAMMING LANGUAGES (1) Representing exceptions: • Built-in exception type • Object derived from an exception class • Any kind of data can be raised as an exception Raising exceptions: • Automatically by the run-time system as a result of an abnormal condition (e.g., division by zero) • throw / raise statement to raise exceptions manually 31/47

  45. EXCEPTION SUPPORT IN PROGRAMMING LANGUAGES (2) Where can exceptions be handled? • Most languages allow exceptions to be handled locally and propagate unhandled exceptions up the dynamic chain. • Clu does not allow exceptions to be handled locally. (How can you simulate local exception handlers?) • PL/I’s exception handling mechanism is similar to dynamic scoping. Some languages require exceptions thrown but not handled inside a subroutine to be declared as part of the subroutine definition. 32/47

  46. EXCEPTION SUPPORT IN PROGRAMMING LANGUAGES (2) Where can exceptions be handled? • Most languages allow exceptions to be handled locally and propagate unhandled exceptions up the dynamic chain. • Clu does not allow exceptions to be handled locally. (How can you simulate local exception handlers?) • PL/I’s exception handling mechanism is similar to dynamic scoping. Some languages require exceptions thrown but not handled inside a subroutine to be declared as part of the subroutine definition. 32/47

  47. HANDLING EXCEPTIONS WITHOUT LANGUAGE SUPPORT • “Invent” a value that can be used instead of a real value normally returned by a subroutine. • Return an explicit “status” value to the caller. The caller needs to check this status. • Rely on the caller to pass a closure to be called in case of an exception. 33/47

  48. EXCEPTION PROPAGATION • Exception handlers in the current scope are examined in order. The first one that “matches” the exception is invoked. • If no matching handler is found, the subroutine exits, and the process is repeated in the caller. • The stack must be unwound (restored to the previous state) and any necessary clean-up needs to be performed (e.g., deallocation of heap objects, closing of file descriptors). Some languages provide support for this using constructs such as Java’s finally clause. 34/47

  49. EXCEPTION PROPAGATION • Exception handlers in the current scope are examined in order. The first one that “matches” the exception is invoked. • If no matching handler is found, the subroutine exits, and the process is repeated in the caller. • The stack must be unwound (restored to the previous state) and any necessary clean-up needs to be performed (e.g., deallocation of heap objects, closing of file descriptors). Some languages provide support for this using constructs such as Java’s finally clause. 34/47

  50. EXCEPTION PROPAGATION • Exception handlers in the current scope are examined in order. The first one that “matches” the exception is invoked. • If no matching handler is found, the subroutine exits, and the process is repeated in the caller. • The stack must be unwound (restored to the previous state) and any necessary clean-up needs to be performed (e.g., deallocation of heap objects, closing of file descriptors). Some languages provide support for this using constructs such as Java’s finally clause. 34/47

  51. EXCEPTION PROPAGATION • Exception handlers in the current scope are examined in order. The first one that “matches” the exception is invoked. • If no matching handler is found, the subroutine exits, and the process is repeated in the caller. • The stack must be unwound (restored to the previous state) and any necessary clean-up needs to be performed (e.g., deallocation of heap objects, closing of file descriptors). Some languages provide support for this using constructs such as Java’s finally clause. 34/47

  52. IMPLEMENTING EXCEPTION HANDLING (1) A simple implementation: • Every subroutine pushes a special exception handler onto the stack that is executed when control escapes the subroutine and performs all necessary clean-up operations. • Every subroutine/protected code block pushes its exception handler onto a handler stack. • Exception handlers with multiple alternatives are implemented using if-then-else or switch statements in the handler. This implementation is costly because it requires the manipulation of the handler stack for each subroutine call/return. 35/47

  53. IMPLEMENTING EXCEPTION HANDLING (1) A simple implementation: • Every subroutine pushes a special exception handler onto the stack that is executed when control escapes the subroutine and performs all necessary clean-up operations. • Every subroutine/protected code block pushes its exception handler onto a handler stack. • Exception handlers with multiple alternatives are implemented using if-then-else or switch statements in the handler. This implementation is costly because it requires the manipulation of the handler stack for each subroutine call/return. 35/47

  54. IMPLEMENTING EXCEPTION HANDLING (1) A simple implementation: • Every subroutine pushes a special exception handler onto the stack that is executed when control escapes the subroutine and performs all necessary clean-up operations. • Every subroutine/protected code block pushes its exception handler onto a handler stack. • Exception handlers with multiple alternatives are implemented using if-then-else or switch statements in the handler. This implementation is costly because it requires the manipulation of the handler stack for each subroutine call/return. 35/47

  55. IMPLEMENTING EXCEPTION HANDLING (1) A simple implementation: • Every subroutine pushes a special exception handler onto the stack that is executed when control escapes the subroutine and performs all necessary clean-up operations. • Every subroutine/protected code block pushes its exception handler onto a handler stack. • Exception handlers with multiple alternatives are implemented using if-then-else or switch statements in the handler. This implementation is costly because it requires the manipulation of the handler stack for each subroutine call/return. 35/47

  56. IMPLEMENTING EXCEPTION HANDLING (1) A simple implementation: • Every subroutine pushes a special exception handler onto the stack that is executed when control escapes the subroutine and performs all necessary clean-up operations. • Every subroutine/protected code block pushes its exception handler onto a handler stack. • Exception handlers with multiple alternatives are implemented using if-then-else or switch statements in the handler. This implementation is costly because it requires the manipulation of the handler stack for each subroutine call/return. 35/47

  57. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  58. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  59. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  60. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  61. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  62. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  63. IMPLEMENTING EXCEPTION HANDLING (2) A faster implementation: • Store a global table mapping the memory addresses of code blocks to exception handlers (can be generated by compiler). • When encountering an exception, perform binary search on the table using the program counter to locate the corresponding handler. Comparison to simple mechanism: • Handling an exception is more costly (binary search), but exceptions should be rare. • In the absence of exceptions, the cost of this mechanism is zero! • Cannot be used if the program consists of separately compiled units and the linker is not aware of this exception handling mechanism. 36/47

  64. EXCEPTIONS IN JAVA AND C++ ... } ... finally { } ... catch (SomeException e2) { } ... catch (SomeException e1) { } ... throw ... try { Java: • Exception declarations on functions not required • Any object can be thrown. • No finally block • throw , try , and catch as in Java C++: • Must declare uncaught checked exceptions. • Only Throwable objects can be thrown. execute no matter what. • finally defines block of clean-up code to • catch defines an exception handler. • try encloses a protected block. • throw throws an exception. 37/47

  65. EXCEPTIONS IN JAVA AND C++ ... } ... finally { } ... catch (SomeException e2) { } ... catch (SomeException e1) { } ... throw ... try { Java: • Exception declarations on functions not required • Any object can be thrown. • No finally block • throw , try , and catch as in Java C++: • Must declare uncaught checked exceptions. • Only Throwable objects can be thrown. execute no matter what. • finally defines block of clean-up code to • catch defines an exception handler. • try encloses a protected block. • throw throws an exception. 37/47

  66. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 38/47

  67. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 38/47

  68. A continuation is the “future” of the current computation, represented as CONTINUATIONS IN SCHEME Scheme does not support exceptions. However, it has a much more general construct that subsumes subroutines, coroutines, exception handling, …: continuations. • Current stack content and referencing environment • Current register content • Current program counter • … Continuations are first-class objects in Scheme: they can be passed as function arguments, returned as function results, and stored in data structures. 39/47

  69. CONTINUATIONS IN SCHEME Scheme does not support exceptions. However, it has a much more general construct that subsumes subroutines, coroutines, exception handling, …: continuations. • Current stack content and referencing environment • Current register content • Current program counter • … Continuations are first-class objects in Scheme: they can be passed as function arguments, returned as function results, and stored in data structures. 39/47 A continuation is the “future” of the current computation, represented as

  70. CONTINUATIONS IN SCHEME Scheme does not support exceptions. However, it has a much more general construct that subsumes subroutines, coroutines, exception handling, …: continuations. • Current stack content and referencing environment • Current register content • Current program counter • … Continuations are first-class objects in Scheme: they can be passed as function arguments, returned as function results, and stored in data structures. 39/47 A continuation is the “future” of the current computation, represented as

  71. CALL-WITH-CURRENT-CONTINUATION IN SCHEME (call-with-current-continuation f) calls function f and passes the current continuation to f as an argument. Simplest possible use: Escape procedure • If f never uses the continuation it was passed as an argument, then everything works as if f had been invoked as (f) . • If f invokes the continuation, then the program state is restored as if f had never been called. Example: Look for the first negative number in a list (call/cc (lambda (exit) (for-each (lambda (x) (if (negative? x) (exit x))) '(54 0 37 -3 245 19)) #t)) 40/47

  72. CALL-WITH-CURRENT-CONTINUATION IN SCHEME (call-with-current-continuation f) calls function f and passes the current continuation to f as an argument. Simplest possible use: Escape procedure • If f never uses the continuation it was passed as an argument, then everything works as if f had been invoked as (f) . • If f invokes the continuation, then the program state is restored as if f had never been called. Example: Look for the first negative number in a list (call/cc (lambda (exit) (for-each (lambda (x) (if (negative? x) (exit x))) '(54 0 37 -3 245 19)) #t)) 40/47

  73. CALL-WITH-CURRENT-CONTINUATION IN SCHEME (call-with-current-continuation f) calls function f and passes the current continuation to f as an argument. Simplest possible use: Escape procedure • If f never uses the continuation it was passed as an argument, then everything works as if f had been invoked as (f) . • If f invokes the continuation, then the program state is restored as if f had never been called. Example: Look for the first negative number in a list (call/cc (lambda (exit) (for-each (lambda (x) (if (negative? x) (exit x))) '(54 0 37 -3 245 19)) #t)) 40/47

  74. CALL/CC FOR EXCEPTION HANDLING (define (list-length obj) (call/cc (lambda (return) (letrec ((r (lambda (obj) (cond ((null? obj) 0) ((pair? obj) (+1 (r (cdr obj)))) (else (return #f)))))) (r obj))))) (list-length '(1 2 3 4)) ; --> 4 (list-length '(a b . c)) ; --> #f 41/47

  75. SETJMP/LONGJMP MECHANISM IN C In C, setjmp / longjmp provide a limited form of continuations: if (!setjmp(buffer)) { /* protected code */ } else { /* handler */ } • The first invocation of setjmp returns 0 and stores the current context (registers, stack pointer, …) in the provided jump buffer. • If no longjmp is performed on the buffer, the then-branch terminates as usual. • If longjmp is invoked, the setjmp returns for a second time, with a non-zero return value, and the handler in the else-branch is executed. 42/47

  76. ROAD MAP • Functions, procedures, and parameters • Inline expansion • Parameter passing modes • Passing functions as arguments • Default and named parameters • Variadic subroutines • Generic subroutines • Exception handling • Continuations • Coroutines 43/47

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

CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013

CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013

CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013 Faculty of Computer Science Dalhousie University 1 / 17 Basic Definitions Subroutines are what we normally call Functions, if they return a

513 views • 17 slides
CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013

CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013

CSCI 3136 Principles of Programming Languages Subroutines and Control Abstraction Summer 2013 Faculty of Computer Science Dalhousie University 1 / 42 Basic Definitions Subroutines are what we normally call Functions, if they return a

610 views • 42 slides
Subroutines Control abstraction Subroutine design If a subroutine does not fit on the

Subroutines Control abstraction Subroutine design If a subroutine does not fit on the

Subroutine Subroutines Control abstraction Subroutine design If a subroutine does not fit on the screen, it is too long Problem should be divided into smaller pieces Subroutine = If some task X is needed twice, make it a

716 views • 23 slides
Assembly Language Programming: Subroutines by Alex Milenkovich, milenkovic@computer.org

Assembly Language Programming: Subroutines by Alex Milenkovich, milenkovic@computer.org

Assembly Language Programming: Subroutines by Alex Milenkovich, milenkovic@computer.org Objectives: Introduce subroutines, subroutine nesting, processor stack, and passing the parameters to subroutines. 1. Subroutines In a given program, it is

198 views • 7 slides
Chapter 5 Subroutines and Functions 5.1 What Are Subroutines and Functions? As your

Chapter 5 Subroutines and Functions 5.1 What Are Subroutines and Functions? As your

Chapter 5 Subroutines and Functions 5.1 What Are Subroutines and Functions? As your applications grow, you need to break them into separate logical units. The code associated with accomplishing each task is separated from the code the

1.21k views • 83 slides
Computer Systems Lecture 12 Subroutines CS 230 - Spring 2020 2-1 Subroutines Also called

Computer Systems Lecture 12 Subroutines CS 230 - Spring 2020 2-1 Subroutines Also called

CS 230 Introduction to Computers and Computer Systems Lecture 12 Subroutines CS 230 - Spring 2020 2-1 Subroutines Also called functions, methods, or procedures all the same thing in assembly language examples from C: sqrt()

798 views • 46 slides
Abstraction refinement and plan revision for control synthesis under high level specifications

Abstraction refinement and plan revision for control synthesis under high level specifications

Abstraction refinement and plan revision for control synthesis under high level specifications Pierre-Jean Meyer Dimos V. Dimarogonas KTH, Royal Institute of Technology July 12 th 2017 Outline Abstraction-based synthesis Global framework

603 views • 34 slides
Point, Line, &amp; Plane 1 Abstraction Abstraction is the act of considering something as a

Point, Line, &amp; Plane 1 Abstraction Abstraction is the act of considering something as a

Point, Line, &amp; Plane 1 Abstraction Abstraction is the act of considering something as a general quality or characteristic, apart from concrete realities, specific objects, or actual instances. 2 Abstraction Abstraction is

478 views • 21 slides
Object-Oriented Programming 1908 Harry Beck, 1933 Abstraction Abstraction is the process of

Object-Oriented Programming 1908 Harry Beck, 1933 Abstraction Abstraction is the process of

Object-Oriented Programming 1908 Harry Beck, 1933 Abstraction Abstraction is the process of capturing only those ideas about a concept that are relevant to the current situation. Irrelevant ideas are left out. Abstraction Control

335 views • 14 slides
Predicate Abstraction with SATABS Existential Abstraction Predicate Abstraction for Software

Predicate Abstraction with SATABS Existential Abstraction Predicate Abstraction for Software

Outline Introduction Predicate Abstraction with SATABS Existential Abstraction Predicate Abstraction for Software Counterexample-Guided Abstraction Refinement Computing Existential Abstractions of Programs Version 1.0, 2010 Checking the

429 views • 12 slides
Framework for Abstraction and Control of Transport Networks

Framework for Abstraction and Control of Transport Networks

Framework for Abstraction and Control of Transport Networks draft-ceccarelli-teas-actn-framework- 00 IETF 93 Prague Daniele Ceccarelli (Ericsson) Young Lee (Huawei) Daniel King (Lancaster-University) Sergio Belotti (Alcatel-Lucent)

621 views • 8 slides
Subroutines and Parameter Passing ECE2893 Lecture 5 ECE2893 Subroutines and Parameter Passing

Subroutines and Parameter Passing ECE2893 Lecture 5 ECE2893 Subroutines and Parameter Passing

Subroutines and Parameter Passing ECE2893 Lecture 5 ECE2893 Subroutines and Parameter Passing Spring 2011 1 / 10 C/C++ Subroutines (Functions) ECE2893 Subroutines and Parameter Passing Spring 2011 2 / 10 C/C++ Subroutines (Functions)

888 views • 62 slides
ARM Cortex-M4 Programming Model Stacks and Subroutines Textbook: Chapter 8.1 - Subroutine

ARM Cortex-M4 Programming Model Stacks and Subroutines Textbook: Chapter 8.1 - Subroutine

ARM Cortex-M4 Programming Model Stacks and Subroutines Textbook: Chapter 8.1 - Subroutine call/return Chapter 8.2,8.3 Stack operations Chapter 8.4, 8.5 Passing arguments to/from subroutines ARM Cortex-M Users Manual, Chapter 3

875 views • 32 slides
Data Abstraction Announcements Data Abstraction Data Abstraction Programmers Compound

Data Abstraction Announcements Data Abstraction Data Abstraction Programmers Compound

Data Abstraction Announcements Data Abstraction Data Abstraction Programmers Compound values combine other values together All A date: a year, a month, and a day A geographic position: latitude and longitude Data abstraction

430 views • 19 slides
Fast quantum subroutines for the simplex method Giacomo Nannicini IBM T.J. Watson research

Fast quantum subroutines for the simplex method Giacomo Nannicini IBM T.J. Watson research

Fast quantum subroutines for the simplex method Giacomo Nannicini IBM T.J. Watson research center, Yorktown Heights, NY nannicini@us.ibm.com Last updated: November 12, 2019. Abstract We propose quantum subroutines for the simplex method that

430 views • 23 slides
Day 5: Subroutines Suggested reading: Learning Perl (4th Ed.) Chapter 4, Subroutines 2012 Summer

Day 5: Subroutines Suggested reading: Learning Perl (4th Ed.) Chapter 4, Subroutines 2012 Summer

Computer Sciences 368 Introduction to Perl Day 5: Subroutines Suggested reading: Learning Perl (4th Ed.) Chapter 4, Subroutines 2012 Summer Cartwright 1 Computer Sciences 368 Introduction to Perl Turn In Homework 2012 Summer Cartwright 2

408 views • 25 slides
An End-to-End Infrastructure for Cyber-Physical Intrusion Detection REINHARD GENTZ, MAHDI JAMEI,

An End-to-End Infrastructure for Cyber-Physical Intrusion Detection REINHARD GENTZ, MAHDI JAMEI,

An End-to-End Infrastructure for Cyber-Physical Intrusion Detection REINHARD GENTZ, MAHDI JAMEI, ANNA SCAGLIONE ARIZONA STATE UNIVERSITY, USA CREDC Workshop 2017 1 What is Cyber Physical Intrusion Detection CPS Cyber Physical System

123 views • 11 slides
CSCE 496/896 Lecture 5: Stephen Scott Autoencoders Introduction Basic Idea Stacked AE Stephen

CSCE 496/896 Lecture 5: Stephen Scott Autoencoders Introduction Basic Idea Stacked AE Stephen

CSCE 496/896 Lecture 5: Autoencoders CSCE 496/896 Lecture 5: Stephen Scott Autoencoders Introduction Basic Idea Stacked AE Stephen Scott Transposed Convolutions Denoising AE (Adapted from Eleanor Quint and Ian Goodfellow) Sparse AE

601 views • 41 slides
Anomalies Detection for HEP Experiments Maxim Borisyak Denis Derkach, Fedor Ratnikov, Andrey

Anomalies Detection for HEP Experiments Maxim Borisyak Denis Derkach, Fedor Ratnikov, Andrey

Anomalies Detection for HEP Experiments Maxim Borisyak Denis Derkach, Fedor Ratnikov, Andrey Ustyuzhanin HEP/ML Group, Yandex School of Data Analysis, National Research University High School of Economics with incredible help from CMS

401 views • 21 slides
Extraction and Applications of Implicit Networks from Unstructured Text Andreas Spitz Heidelberg

Extraction and Applications of Implicit Networks from Unstructured Text Andreas Spitz Heidelberg

Extraction and Applications of Implicit Networks from Unstructured Text Andreas Spitz Heidelberg University, Institute of Computer Science Database Systems Research Group spitz@informatik.uni-heidelberg.de Max Planck Institute for Informatics

884 views • 76 slides
EE 109 Unit 15 Subroutines Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF

EE 109 Unit 15 Subroutines Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF

1 2 EE 109 Unit 15 Subroutines Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF RELEVANT CONCEPTS Stacks 3 4 Review of Program Counter GPR's Used for Subroutine Support Assembler Name Reg. Number Description PC is

70 views • 6 slides
Stack 2 Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF RELEVANT CONCEPTS 3

Stack 2 Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF RELEVANT CONCEPTS 3

1 EE 109 Unit 11 Subroutines and Stack 2 Program Counter and GPRs (especially $sp, $ra, and $fp) REVIEW OF RELEVANT CONCEPTS 3 Review of Program Counter PC is used to fetch an instruction PC contains the address of the next

693 views • 35 slides
CHAPTER XV PROCEDURE CALLS AND SUBROUTINES R.M. Dansereau; v.1.0 MIPS ASSEMBLY INTRO. TO COMP.

CHAPTER XV PROCEDURE CALLS AND SUBROUTINES R.M. Dansereau; v.1.0 MIPS ASSEMBLY INTRO. TO COMP.

INTRO. TO COMP. ENG. CHAPTER XV CHAPTER XV-1 PROCEDURE CALLS CHAPTER XV PROCEDURE CALLS AND SUBROUTINES R.M. Dansereau; v.1.0 MIPS ASSEMBLY INTRO. TO COMP. ENG. ISA PROGRAM PATH CHAPTER XIII-5 -TRANSLATING CODE MIPS REGISTER

558 views • 21 slides
The Fortran 90 programming language Fortran has evolved since the early days of computing

The Fortran 90 programming language Fortran has evolved since the early days of computing

The Fortran 90 programming language Fortran has evolved since the early days of computing Fortran 90/95 is a modern programming language Many useful features for scientific (numerical) computing Widely used language in computational

550 views • 35 slides

More recommend