1 / 16

ICS 313: Programming Language Theory

ICS 313: Programming Language Theory. Module 09: Functional Programming. Objectives. Understand concepts of functional languages (You do not need to learn syntax of a specific language for this module.) Warning: Sebesta’s knowledge of Lisp is dated (no mention of CLOS, for example.).

gerodi
Download Presentation

ICS 313: Programming Language Theory

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. ICS 313:Programming Language Theory Module 09: Functional Programming

  2. Objectives • Understand concepts of functional languages • (You do not need to learn syntax of a specific language for this module.) • Warning: Sebesta’s knowledge of Lisp is dated (no mention of CLOS, for example.)

  3. Imperative vs. Non-imperative Paradigms • Imperative: • Based upon efficient use of Von Neumann architecture • Imperative languages are simply “glorified machine languages” • Non-imperative: • Based upon non-architectural issues: • Functional: lambda calculus • Logic: Inference/deduction • Object orientation: data abstraction/encapsulation

  4. Characteristics of functional paradigm • 1. Referential transparency • 2. Automatic storage management • 3. Higher order functions • 4. Lazy evaluation • common in functional languages, but not strictly necessary for the functional paradigm.

  5. 1. Referential Transparency • “The value of an expression depends only upon the values of its subexpressions.” • Rules out side effects and therefore assignment statements. • Execution of a function always gives the same values when given the same parameters. • Issue: How to represent things like bank accounts? • get-balance(acct) • add-deposit(acct, deposit) • get-withdrawal(acct, withdrawal)

  6. 2. Automatic storage management • Since functional paradigm does not represent memory, system must handle memory management for the programmer. • Requires a garbage collector • Makes programs more simple and shorter • Can make programs run more slowly • (since garbage collector must keep track) • Can make programs more reliable • (since no dangling pointers)

  7. 3. Higher Order Functions • Two flavors of functions: • First order functions (traditional) • Higher order functions

  8. First order functions • Arguments and results are both values: • (defun add2 (val) (+ 3 val)) • Add2 accepts a single argument, val, and returns the result of adding 3 to val. • (add2 3) • Invokes the add2 function with 3. • 3 is bound to val • (+ 3 val) is evaluated with val bound to 3 • 6 is returned • Both imperative and functional languages have first order functions.

  9. Higher order functions • Accepts functions as arguments and/or return new functions as results. • Examples: • sort (list less-than-pred) -> list • sort-generater (less-than-pred) -> sort (list) -> list • Implies that functions are treated just like data: • returned as the value of expressions • stored in data structures • passed as arguments to other functions • generated/manipulated at run time

  10. 4. Lazy evaluation • Two flavors of evaluation: • Eager evaluation (traditional) • Lazy evaluation

  11. Eager Evaluation • Also known as innermost or applicative order evaluation • Given: f (E1, E2) • Evaluate arguments E1 and E2 and determine their values • Bind the values of E1 and E2 to the parameters defined in the function body • Evaluate the function body and return its value

  12. Lazy Evaluation • Also known as outermost or normal order evaluation • Given: f (E1, E2) • Bind arguments E1 and E2 to corresponding parameters without evaluating them. • Evaluate the function body, determining the value of E1 and E2 only when actually needed. • Allows manipulation of infinite data structures (streams)

  13. Lazy Evaluation Example • Arguments to a function are not evaluated until their values are actually used. • Consider: • An infinite list with elements (1, 2, 3, 5, 8, 13, ....) • nth element is sum of the n-1 and n-2 elements • Typical list operations: • nth (list n) Returns sum of the first n elements • member (list element) Returns true if ELEMENT is a member of LIST • Under lazy evaluation, only that part of the list needed to determine the sum would be computed.

  14. Lazy and Eager evaluation lead to programs with different semantics • Example: • int weird (int a, int b) { if (a == 0) return (a); else return (b);} • What is the value of weird (0, (1 / 0)) under: • Eager evaluation • Lazy evaluation

  15. Support for functional paradigm • Ada and Pascal • No support • C and C++: • Partial support for higher order functions • Pointers to functions can be passed and returned from procedures • Functions cannot be generated dynamically • Common Lisp: • Automatic storage management • Higher order functions • Pure functional languages (ML, Miranda, Haskell) • Support all features of functional languages

  16. End of Module 09

More Related