Download functional form

Chapter Fifteen: Functional
Programming Languages
Lesson 12
Basis of design
The design of the functional languages is based on the
concept of functions in mathematics

1 if n  0
f ( n)  
n * f (n  1) if n  0
1 if n  0

fib(n)  1 if n  1
 fib(n  2)  fib(n  1) otherwise

Set notation
factors(n)  i | i 1..n / 2, n%i  0
2
Functional Programming Languages
4/29/2017
Mathematical Function


Domain and range, a mapping
No side effects
Range


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
Domain
3
Functional Programming Languages
4/29/2017
Name vs. definition
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)

4
Functional Programming Languages
4/29/2017
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
5
Functional Programming Languages
4/29/2017
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
Functional Programming Languages
4/29/2017
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


7
Functional Programming Languages
4/29/2017
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)
8
Functional Programming Languages
4/29/2017
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)
Key is they are bound at the
time of definition or function
invocation: can’t change
9
Functional Programming Languages
4/29/2017
LISP: first functional program

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
10
Functional Programming Languages
4/29/2017
Functions that build code
(DEFINE (adder lis)
(COND
((NULL? Lis) 0)
(ELSE (EVAL (CONS ‘+ lis)))
))


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
11
Functional Programming Languages
4/29/2017
LISP early design

Intention was to have a notation as similar to Fortran’s as
possible


The development of the EVAL interpreter probably
derailed this effort



M-notation, for meta-notation
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
Notation and Interpretation
12
Functional Programming Languages
4/29/2017
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


13
3::[5,5,9] yields [3,5,5,9]
Replaced car and cdr with hd and tl functions or h::t as an
argument
Functional Programming Languages
4/29/2017
ML continued

Used prototypes (overloading, or pattern matching) in
place of cond (condition checking)
fun
|

length([]) = 0
length(h :: t) = 1 + length(t);
Function declaration form:


fun name (parameters) = body;
e.g., fun cube (x : int) = x * x * x;
Result: notation more like mathematical notation
fun
|
14
fact(0) = 1
fact(n : int) : int = n * fact(n – 1)
Functional Programming Languages
4/29/2017
Haskell: more evolution




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
15
Functional Programming Languages
4/29/2017
List Comprehension (Haskell continued)
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.


factors(n)  i | i 1..n / 2, n%i  0
Set notation
All of the factors of its given parameter:
factors n = [i | i <- [1..n `div` 2],
n `mod` i == 0]
16
Functional Programming Languages
4/29/2017
Quicksort (Haskell continued)
++ is concatenate
sort [] = []
sort (h:t) =
sort [b | b <- t; b <= h] ++
[a] ++
sort [b | b <- x; b > a]


Considerably shorter than an imperative language
17
Functional Programming Languages
4/29/2017
Strict languages (Haskell continued)


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
Guards
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
18
Functional Programming Languages
4/29/2017
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
19
Functional Programming Languages
4/29/2017
Functional vs. Imperative
What do you think?


Proponents
use examples like quicksort to support the
oFaster development?
notion that programs are less complex and more
readable than imperative
oCould you get away with no interpretation?
The opposition says that interpretation makes it less
efficient
oIs it more readable? In all cases?
20
Functional Programming Languages
4/29/2017
The end
21
Functional Programming Languages
4/29/2017