Functional Relational

Programming
Waging War on Complexity
Waging War on Complexity
Waging War on Complexity

SPA 2006

Ben Moseley Peter Marks

ben@moseley.name public@indigomail.net
 Overview
• Part 1: Complexity

Types of complexity
• Sources of complexity
• Part 2: Functional Relational Programming

Functions & Relations

• High-level architecture

Worked Example

Ben Moseley & Peter Marks SPA 2006

 Conclusions
most
• State is the root of all evils

Much complexity in our software is non-

essential
• Constraining our systems to only explicitly
possessing essential state offers great
promise in helping to control complexity
• Separating non-essential control from
essential logic reduces system complexity
• FRP looks interesting and worth finding out
more about

Ben Moseley & Peter Marks SPA 2006

 “The complexity of software is
an essential property”
Fred Brooks, “No silver bullet”, 1987

Ben Moseley & Peter Marks SPA 2006

 Complexity
Complexity curve

Development
Ben Moseley & Peter Marks SPA 2006
 Accidents and Essence

• Essential Complexity is inherent in, and the

essence of, the problem
• Accidental Complexity is associated with
building a system to solve the problem

Ben Moseley & Peter Marks SPA 2006

 What was wrong with
4GLs?
• They weren’t very good languages

Did not make the paradigm shift

• Hardware wasn’t fast enough
• Degenerated to bad 3GLs
• … but RDBMSs and Spreadsheets exploded

Ben Moseley & Peter Marks SPA 2006

 Manifestations of
Complexity

• State

Control
• Code Volume

Expression

Ben Moseley & Peter Marks SPA 2006

 Example: Quick Sort
Optimisation to sort in
place
qsort( int a[], int lo, int hi ) { t = a[l];
int h, l, p, t; a[l] = a[hi]; Missing abstraction
a[hi] = t;
if (lo < hi) {
l = lo; Unclear: should not include qsort( a, lo, l-1 ); Arbitrary
h = hi; hi qsort( a, l+1, hi );
order
p = a[hi]; }
Poor }
do { naming

X
while ((l < h) && (a[l] <= p))
l = l+1; Arbitrary order
while ((h > l) && (a[h] >= p))
h = h-1;
if (l < h) {
Transient state
t = a[l];
a[l] = a[h];
Duplication
a[h] = t;
}
} while (l < h); Specific algorithm

Ben Moseley & Peter Marks SPA 2006

 Activity: Wood and
Trees

• Working in groups of four

Examine a non-trivial software system

• Distill its essence then focus on what
remains

Attribute the accidents…

Ben Moseley & Peter Marks SPA 2006

 Accidental Complexity
State
•What can be derived?
•What is purely transient?

•Control
When is order unimportant?
•Expression
•Duplication or redundancy
•Inconsistency (particularly of idiom)
•Missing abstraction
•Unnecessary abstraction

Ben Moseley & Peter Marks SPA 2006

 Activity: Thinning

• Classify accidental complexity instances

Platform
• Language

Effluent – unwanted byproduct

Ben Moseley & Peter Marks SPA 2006

End of Part 1
 Part 2 - Overview
• Review of Complexity

Functional Relational Programming

• Functions & Relations
• High-level architecture

Worked Example
• Exercise & Discussion

Ben Moseley & Peter Marks SPA 2006 14

? Complexity Review

Accidental Essential

Accidental Complexity Essential Complexity

 Desired Architecture

Accident
Essential
al

Infrastructure

Ben Moseley & Peter Marks SPA 2006

 Objects...?

o
bj o
bj o
bj
o

...NO!!
bj

Ben Moseley & Peter Marks SPA 2006

 Functional
Programming
Pure FP avoids state
completely
•Better to think of FP as a useful technique
rather than a group of languages

Immutability

Passing and returning Functions

•Advantages: Reasoning, Expressivity,
Speed

Ben Moseley & Peter Marks SPA 2006

 Relational Model
• Familiar from database world ...

...but... Relational Model ≠ SQL !!!

• Powerful and flexible

Sound mathematical foundation

name grou dob

p
ben 7 21/05/74
sam 4 03/05/81
jon 3 17/06/92
mark 4 12/11/89

Ben Moseley & Peter Marks SPA 2006

 Relational Model
• Structural component is based on Sets
• So, no duplicates & ordering irrelevant
name grou dob name
dob grou name
dob
p p
ben 7 21/05/74 21/05/74
17/06/92
ben
jon 7
3 21/05/74
17/06/92
ben
jon
sam 4 03/05/81 03/05/81
12/11/89
mark
sam 4 03/05/81
12/11/89
mark
sam
jon 3 17/06/92 17/06/92
21/05/74
ben
jon 3
7 17/06/92
21/05/74
ben
jon
mark 4 12/11/89 12/11/89
03/05/81
mark
sam 4 12/11/89
03/05/81
mark
sam

Ben Moseley & Peter Marks SPA 2006

 Relational Model
• Structure
USERS
Manipulation
(Relational Algebra - not name grou dob
SQL!) p
ben 7 21/05/74
sam 4 03/05/81
• Integrity jon 3 17/06/92
mark 4 12/11/89
Data Independence

Ben Moseley & Peter Marks SPA 2006

 Functional Relational
Programming
• What is FRP?
• A new (as far as we know), unproven
way of building large systems
• Based on some old ideas
• Aims for SIMPLICITY above all else
• An (internal) Architecture not Language...

Ben Moseley & Peter Marks SPA 2006

 FRP Architecture

Accident Essential
al

Infrastructure

Ben Moseley & Peter Marks SPA 2006

 FRP Architecture

Accident Essential
al Logic
State &
Control
Essential
State

Infrastructure

Ben Moseley & Peter Marks SPA 2006

 Essential
dent
Logic
Essential
al
State
Stat
d
e&
Cont
e
Es
Es
rol
Infrastructure

FRP
n
se
se Architecture
t
nti
Infras
nti
tructu
aal
alre
lc
Logi
Stat
Ste
at
e
& Interfaces
Co
nt
rol

Relations
Function
Ben Moseley & Peter Marks SPA 2006
s
 Essential
dent
Logic
Essential
al
State
Stat
e&
Cont
rol
Infrastructure

FRP Running Example

• Editorial system for a Journal

• People submit Papers, Chief Editor posts
them for Review (on private editorial
website), they are Rejected / Accepted and
Published
• Main Entities: Paper, Journal
• Each Paper conceptually has a lifecycle...

Ben Moseley & Peter Marks SPA 2006

 Paper
Essential
dent
Logic
Essential
al
State
Stat
e&
Cont
rol
Infrastructure

Lifecycle
Lifecycle
Under
Proposed Rejected
Review

Awaiting Accepted
Correction
s
Publishe
(“State” Transition Diagram)
d
Ben Moseley & Peter Marks SPA 2006
 Essential
Accidenta
Logic

Essential State
l
State &
Essential
Control
State

Infrastructure

• This consists solely of definitions of

Relations representing the user’s inputs to
the system
• Basically just a schema for the inputs
• The whole system will be driven by users
updating these input relations at runtime
• No Derived values here (since not
“essential” they be stored rather than
rederived)

Ben Moseley & Peter Marks SPA 2006

 Essential State Accidenta
l
State &
Essential
Logic

Example
Essential
Control
State

Infrastructure

PAPER OPINION
paper autho submitte paper reviewer opinion
DB Theory r
ian d
21/05/06 DB Theory adam GOOD
Pi Calculus sam 03/05/06 DB Theory fred BAD
OODBs tim 17/06/06 Pi Calculus adam GOOD
Ruby On
bob 12/11/06 Pi Calculus fred GOOD
Rails
Pi Calculus simon GOOD
Ruby On
adam GOOD
RailsOn
Ruby
POSTING fred GOOD
RailsOn
Ruby
paper posted simon GOOD
Rails
DB Theory 23/05/06 JOURNAL
Pi Calculus 05/05/06 issue paper
Ruby On Rails 15/11/06
17 Pi Calculus
18 Ruby On Rails

Ben Moseley & Peter Marks SPA 2006

 Essential
Accidenta
Logic

Essential Logic
l
State &
Essential
Control
State

Infrastructure

• Definitions of Derived Relations

• i.e. intermediate and output relations
• Defined in terms of Essential State
relations
• Uses relational algebra (not SQL!)
• Uses (pure) user-defined functions
• Essentially similar to View defns in an
RDBMS
Ben Moseley & Peter Marks SPA 2006
 Essential
Accidenta
Logic

Essential Logic
l
State &
Essential
Control
State

Infrastructure

• Integrity Constraints
• Not concerned with State at all (eg
provides no facilities for manipulating
State)

Ben Moseley & Peter Marks SPA 2006

 Essential Logic Accidenta
l
State &
Control
Essential
Logic

Essential
State

Example Infrastructure

OPINION
OVERVIEW paper reviewer opinion
paper opinion DB Theory adam GOOD
DB Theory GOOD DB Theory fred BAD
DB Theory BAD Pi Calculus adam GOOD
Pi Calculus GOOD Pi Calculus fred GOOD
Ruby On Pi Calculus simon GOOD
GOOD
Rails Ruby On
adam GOOD
RailsOn
Ruby
fred GOOD
RailsOn
Ruby
simon GOOD
Rails

OVERVIEW = project(OPINION, paper opinion)

Ben Moseley & Peter Marks SPA 2006

 Essential Logic Accidenta
l
State &
Control
Essential
Logic

Essential
State

Example Infrastructure

OPINION
BAD_OPINIONS paper reviewer opinion
paper reviewer opinion DB Theory adam GOOD
DB Theory fred BAD DB Theory fred BAD
Pi Calculus adam GOOD
Pi Calculus fred GOOD
Pi Calculus simon GOOD
Ruby On
adam GOOD
RailsOn
Ruby
fred GOOD
RailsOn
Ruby
simon GOOD
Rails

BAD_OPINIONS = restrict(OPINION |
opinion == BAD)
Ben Moseley & Peter Marks SPA 2006
 Essential Logic Accidenta
l
State &
Control
Essential
Logic

Essential
State

Example Infrastructure

REJECTED BAD_OPINIONS
paper paper reviewer opinion
DB Theory DB Theory fred BAD

REJECTED = project(BAD_OPINIONS, paper)

Ben Moseley & Peter Marks SPA 2006

 Essential Logic Accidenta
l
State &
Control
Essential
Logic

Essential
State

Example Infrastructure

OPINION
GOOD_OPINIONS paper reviewer opinion
paper reviewer opinion DB Theory adam GOOD
DB Theory adam GOOD DB Theory fred BAD
Pi Calculus adam GOOD Pi Calculus adam GOOD
Pi Calculus fred GOOD Pi Calculus fred GOOD
Pi Calculus simon GOOD Pi Calculus simon GOOD
Ruby On Ruby On
adam GOOD adam GOOD
RailsOn
Ruby RailsOn
Ruby
fred GOOD fred GOOD
RailsOn
Ruby RailsOn
Ruby
simon GOOD simon GOOD
Rails Rails

GOOD_OPINIONS = restrict(OPINION |
opinion == GOOD)
Ben Moseley & Peter Marks SPA 2006
 Essential Logic Accidenta
l
State &
Control
Essential
Logic

Essential
State

Example Infrastructure

REJECTED
paper GOOD_OPINIONS
DB Theory paper reviewer opinion
DB Theory adam GOOD
ACCEPTED...
ACCEPTED Pi Calculus adam GOOD
paper Pi Calculus fred GOOD
DBCalculus
Theory Pi Calculus simon GOOD
Pi Ruby On
Ruby On adam GOOD
Pi Calculus RailsOn
Ruby
RailsOn
Ruby fred GOOD
RailsOn
Ruby
Rails simon GOOD
Rails

ACCEPTED = minus(project(GOOD_OPINIONS, paper),

REJECTED)
Ben Moseley & Peter Marks SPA 2006
 Essential
Accidenta
Logic

Essential Logic
l
State &
Essential
Control
State

Infrastructure

SCORE OPINION
paper reviewer score paper reviewe score opinion
DB Theory adam 98% DB Theory r
adam 98% GOOD
DB Theory fred 48% DB Theory fred 48% BAD
Pi Calculus adam 79% Pi Calculus adam 79% GOOD
Pi Calculus fred 73% Pi Calculus fred 73% GOOD
Pi Calculus simon 74% Pi Calculus simon 74% GOOD
Ruby On Ruby On
adam 83% adam 83% GOOD
RailsOn
Ruby RailsOn
Ruby
fred 89% fred 89% GOOD
RailsOn
Ruby RailsOn
Ruby
simon 77% simon 77% GOOD
Rails Rails

OPINION =
extend(SCORE,
opinion=opinionFromScore(score))
Ben Moseley & Peter Marks SPA 2006
 Essential
Accidenta
Logic

Essential Logic
l
State &
Essential
Control
State

Infrastructure

• Comprised of:
• Derived Relations
• User-defined functions
• Constraints
• No State, no Control

Ben Moseley & Peter Marks SPA 2006

 Accidental State & Accidenta
l
State &
Control
Essential
Logic

Essential
State

Control (ie Performance) Infrastructure

• Basically this is just a configuration file:

• Declarative specification of where State
should be used
• Declarative specification of what Control
should be used (eg which bits should be
eager, which lazy)
• Has NO affect whatsoever on the logic (i.e.
correctness) of the system

Ben Moseley & Peter Marks SPA 2006

 Essential
Accidenta
Logic

Infrastructure
l
State &
Essential
Control
State

Infrastructure

• Completely independent of all the rest of

the system - totally “system-agnostic”
• Can be written fairly easily in any language
(eg 2000 LOC Java, 1500 LOC Scheme)
• Determines what performance settings are
available to the Accidental component
• May provide type-checking, basic functions
etc

Ben Moseley & Peter Marks SPA 2006

 Activity - DVD Rentals

• System to manage DVD Store:

• Give info about Stock
• Give info about Rentals
• Assume the existence of any useful
function
• Don’t worry about Syntax!

Ben Moseley & Peter Marks SPA 2006

Functional Relational
Programming

SPA 2006

Ben Moseley Peter Marks

ben@moseley.name public@indigomail.net