Can programming be liberated from the von neumann style?

1. Can programming be
liberated from the
von Neumann style?
Backus J. Can programming be liberated from the von Neumann style?:
a functional style and its algebra of programs.
Commun ACM 1978;21:613–41.
Oriol López Massaguer
Barcelona CompSci Club meetup
8/10/2014

2. Background
• Who was John Backus?
• Creator of FORTRAN. IBM 1954. First high level language compiler
• Member of the ALGOL committee
• BNF formalism (syntax of programming languages)
• Programming languages & software development in the 70s
• OO languages not in widespread use
• Programming languages used: Fortran, COBOL and Algol
• High level languages became wide and increasingly complex: Ada,
Algol, etc..
• Software crisis: increasing difficulty of software projects
• Turing award
• Recipients give a lecture during the ACM meeting
• Since 1966
• Recipients: Knuth, Dijkstra, Codd, John McCarthy, Hoare, Cerf, Kay,
etc.

3. Von Neumann computer & languages
What are Von Neumann Languages?
• Conventional languages are Von Neumann languages
because they are high level versions of Von Neumann
computer
• The most important statement is assignment. To compute
something is to store the result in a memory cell
• All the other constructs are auxiliary to make assignments
• Assignment is both:
• performance bottleneck
• intellectual bottleneck
• Despite the evolution from FORTRAN to ALGOL
(essentially the same) and even to today (2014)
programming languages they are essentially the same

4. Models of Computing systems
Simple
Operational
Models
Applicative models Von Neumann
models
Examples Turing machines
automata
Lambda calculus
Combinators
Pure LISP,
FP systems.
Von Neumann
comps,
Conventional
programming
languages
Semantics State transition
(simple state)
Reduction semantics
(no state)
State transition
(complex state)
Program clarity Unclear
Not conceptually
helpful
Clear
Conceptually
helpful
Clear
Not very useful
conceptually

5. Solution proposed
Functional programming systems (FP systems)
Structure / Syntax:
• A set of objects O
• A set of functions F. Map objects into objects
• An operation, application
• A set of functional forms. Combine F and O to build new functions
in F
• A set of definitions that define some functions in F and assign a
name to each definition
Behavior / Operational:
• Computation of some f:x is the evaluation of the expression
according to the described rules
Semantics:
• Semantics is a reduction semantics. No state. The expression has
the whole meaning of the computation.

6. Solution proposed
FP systems:
• A set of objects O
• Atoms: 1, 2, ┴, T, F
• Sequences: <x1, x2,…, xn>
• Application:
• Given function f and object o:
• f:x denotes the application of f to o

7. Solution proposed
• Functions:
• Selector:
• 1: < 푥1,, 푥2, … , 푥푛 >→ 푥1
• Tail:
• 푡푙: 푥 ≡ < 푥1,, 푥2, … , 푥푛 >→: < 푥2, … , 푥푛 >
• Atom predicate, equality predicate, null predicate
• Reverse (reverse a sequence)
• Distribute (pair an element with all elements of a sequence)
• Transpose (matrix transposition)
• Arithmetic operators, logical operators, etc.

8. Solution proposed
• Functional forms:
• Composition:
• 푓 ∘ 푔 : 푥 ≡ 푓: (푔: 푥)
• Condition:
• 푝 → 푓; 푔 ∶ 푥 ≡ 푝 ∶ 푥 = 푇 → 푓: 푥 ; 푝 ∶ 푥 = 퐹 → 푔: 푥
• Constant
• 푥 : 푦 ≡ 푦 = ⊥ → ⊥ ; 푥
• Insert (aka fold):
• /푓: 푥 ≡ 푥 = < 푥1 > → 푥1; 푥 =< 푥1, … , 푥푛 > & 푛 ≥ 2 → 푓: < 푥1,/푓: < 푥2, … , 푥푛 > > ; ⊥
• Apply to all (aka map)
• While
In summary a set of predefined higher-order functions.

9. Solution proposed
• Definitions:
• 퐷푒푓 푓 ≡ 푟(푓)
• l is a unused functional symbol
• r is a functional form which may depend on f (in case of recursion)
• Example (function to obtain the last element of a list)
• 퐷푒푓 푙푎푠푡 ≡ 푛푢푙푙 ∘ 푡푙 → 1 ; 푙푎푠푡 ∘ 푡푙
• Haskell syntax:
• last [x] = x
• last (_:xs) = last xs
• Example (inner product)
• 퐷푒푓 퐼푃 ≡ (/+) ∘ ∝× ∘ 푡푟푎푛푠
• Haskell syntax:
• ip l1 l2 = foldl (+) 0 (map2 (*) l1 l2)

10. Limitations of FP systems
Limitations of FP systems:
• can not compute an FP program
• since functions expressions are not objects
• can not define new functional forms
• no state concept. no I/O
Extensions
• Formal systems for functional programming (FFP)
• FP systems + possibility of creating new functional forms
• Applicative State Transition (AST) Systems
• Proposes an hybrid language that
• An applicative subsystem (such as FFP)
• A state D (the set of definitions of the applicative subsystem)
• A set of transition rules to define the I/O transformations and the D state transitions

11. Goals of the solution
Improve reasoning about the software developed
• Programs as a certain kind of algebraic expressions
• Verify correctness by following equational reasoning on
the programs
• This algebra is mathematically simpler than the classical
approach to verify program correctness in von Neumann
languages (Dijkstra, Hoare, etc.)
Improve the research on new architectures to execute
applicative languages more efficiently
• Some attempts of graph reduction machines in the early
80s, but failed

12. Today, has programming been liberated
from von Neumann style?
Global failure of the program
• FP is not mainstream
• We didn’t have new architectures for applicative languages
But:
• Some FP constructs / ideas are becoming mainstream
• Closures / Higher order functions / Pattern matching / for comprehensions
• Some people claim that concurrency may be easier by using FP
techniques (due to stateless nature)
• Multicore architectures require new programming tools. Some people
claim that FP will ease development
• But some questions remain open in the FP paradigm
• Lazy evaluation / strict evaluation: Haskell vs ML
• Modelling imperative computations: I/O, state, etc.
• Pure functional language + Monads: Haskell approach
• Hybrid / impure approach: Scala, ML, F#, OCAML

13. References
• Backus J. Can programming be liberated from the von Neumann style?: a
functional style and its algebra of programs. Commun ACM 1978;21:613–41.
• Hudak P. Conception, evolution, and application of functional programming
languages. ACM Comput Surv 1989;21:359–411.
• Wadler P. The essence of functional programming. Proc. 19th ACM
SIGPLAN-SIGACT Symp. Princ. Program. Lang., 1992, p. 1–14.
• Wadler P. Comprehending monads. Math Struct Comput Sci 1992;2:461.
• Hughes J. Why functional programming matters. Comput J 1989:1–23.
• Bird R, Moor O de. The algebra of programming. 1997.