1. Chapter Fifteen: Functional Programming Languages Lesson 12

2. Basis of design  The design of the functional languages is based on the concept of functions in mathematics 6/4/20162Functional Programming Languages Set notation

3. Mathematical Function  Domain and range, a mapping  No side effects  The result of f(x) is always the same  Referential Transparency - the evaluation of a function always produces the same result given the same parameters 6/4/20163Functional Programming Languages Domain Range

4. Name vs. definition 6/4/20164Functional Programming Languages  Early theoretical work separated the task of defining a function from that of naming the function  A lambda expression is an unnamed function  Example  The named function  cube (x) = x * x * x  The unnamed function  (x) x * x * x  Remember: a function is an expression (resolves to a value)

5. Lambda functions  Useful if you want to define a function at the point of application  Church developed lambda calculus  Very much drove development of functional programming languages  Kind of an alternative to Turing machine approach  Turing=imperative  Church=functional (LAMBDA (x) (* x x x) ((LAMBDA (x) (* x x x)) 3) Returns 27 ((LAMBDA (x) (* x x x)) 3) Returns 27 6/4/20165Functional Programming Languages

6. Functional Forms  A higher-order function, or functional form, is one that either takes functions as parameters or yields a function as its result, or both 6/4/20166Functional Programming Languages

7. Function Composition  A functional form that takes two functions as parameters and yields a function whose value is the first actual parameter function applied to the application of the second   means is defined as Form: h  f ° g which means h (x)  f ( g ( x)) For f (x)  x + 2 and g (x)  3 * x, h  f ° g yields (3 * x)+ 2 6/4/20167Functional Programming Languages

8. Apply-to-all  A functional form that takes a single function as a parameter and yields a list of values obtained by applying the given function to each element of a list of parameters Form:  (apply to all) For h(x)  x * x (is defined as)  ( h, (2, 3, 4)) yields (4, 9, 16) 6/4/20168Functional Programming Languages

9. No variables that model memory locations  In an imperative language its all about the variables  They can be set, and then reset Examples of function definition (LAMBDA (x) (* x x x)) Example of a symbolic representation (DEFINE pi 3.14159) Examples of function definition (LAMBDA (x) (* x x x)) Example of a symbolic representation (DEFINE pi 3.14159) Key is they are bound at the time of definition or function invocation: can’t change 6/4/20169Functional Programming Languages

10. LISP: first functional program 6/4/201610Functional Programming Languages  Turing machines were essentially programs  Memory was tape  Universal Turing machine could read a representation of a Turing machine from the Tape and implement the actions of that representation  Early LISP research developed a “universal function” that could evaluate any other function: EVAL  This effectively became the first LISP interpreter EVAL: universal function; first interpreter

11. Functions that build code  Can build a new list on the fly and insert the name of a function and pass this to EVAL  In essence, letting a function write a function 6/4/201611Functional Programming Languages (DEFINE (adder lis) (COND ((NULL? Lis) 0) (ELSE (EVAL (CONS ‘+ lis))) ))

12. LISP early design  Intention was to have a notation as similar to Fortran’s as possible  M-notation, for meta-notation  The development of the EVAL interpreter probably derailed this effort  Meant that the form for submitting functions became the norm  S-expressions for symbolic expressions (the list form)  It also made interpretation the norm for functional languages 6/4/2016Functional Programming Languages12 Notation and Interpretation

13. The evolution of functional languages  ML: MetaLanguage1970’s  More imperative  A bit more readable  Infix vs. prefix: 3 + 5 vs. + 3 5  Moved parens to encapsulate arguments: f(x) vs. (f x)  Did away with cons and appended to lists with “::” notation  3::[5,5,9] yields [3,5,5,9]  Replaced car and cdr with hd and tl functions or h::t as an argument 6/4/2016Functional Programming Languages13

14. ML continued  Used prototypes (overloading, or pattern matching) in place of cond (condition checking) funlength([]) = 0 | length(h :: t) = 1 + length(t);  Function declaration form:  fun name (parameters) = body;  e.g., fun cube (x : int) = x * x * x; 6/4/2016Functional Programming Languages14 Result: notation more like mathematical notation fun fact(0) = 1 |fact(n : int) : int = n * fact(n – 1) fun fact(0) = 1 |fact(n : int) : int = n * fact(n – 1)

15. Haskell: more evolution 6/4/201615Functional Programming Languages  1990, pronounced [ ˈ hæsk ə l],  Named after logician Haskell Curry  Same readability as ML but purely functional  Same pattern matching (though without the pipe and fun) fact 0 = 1 fact n = n * fact (n – 1)  Fibonacci fib 0 = 1 fib 1 = 1 fib (n + 2) = fib (n + 1) + fib n

16. List Comprehension (Haskell continued)  Set notation  All of the factors of its given parameter: factors n = [i | i <- [1..n `div` 2], n `mod` i == 0] 6/4/201616Functional Programming Languages A list comprehension is a syntactic construct available in some programming languages for creating a list based on existing lists. It follows the form of the mathematical set-builder notation (set comprehension) as distinct from the use of map and filter functions.

17. Quicksort (Haskell continued)  ++ is concatenate sort [] = [] sort (h:t) = sort [b | b <- t; b <= h] ++ [a] ++ sort [b | b a]  Considerably shorter than an imperative language 6/4/201617Functional Programming Languages

18. Strict languages (Haskell continued) 6/4/201618Functional Programming Languages  A language is strict if it requires all actual parameters to be fully evaluated  Nonstrict languages are more efficient and allow some interesting capabilities – infinite lists Determining if 16 is a square number member (m:x) n | m < n = member x n | m == n = True | otherwise = False squares = [n * n | n <- [0..]] member squares 16 Determining if 16 is a square number member (m:x) n | m < n = member x n | m == n = True | otherwise = False squares = [n * n | n <- [0..]] member squares 16 Guards

19. Lazy evaluation (Haskell continued)  Only compute those values that are necessary  Like threads  Positive numbers positives = [0..]  Determining if 16 is a square number member [] b = False member(a:x) b = (a == b)||member x b squares = [n * n | n <- [0..]] member squares 16 6/4/2016Functional Programming Languages19 [ ]

20. Functional vs. Imperative  Proponents use examples like quicksort to support the notion that programs are less complex and more readable than imperative  The opposition says that interpretation makes it less efficient 6/4/2016Functional Programming Languages20 What do you think? o Faster development? o Could you get away with no interpretation? o Is it more readable? In all cases? What do you think? o Faster development? o Could you get away with no interpretation? o Is it more readable? In all cases?

21. The end 6/4/201621Functional Programming Languages