Levels of Abstraction
Learning Outcomes
· Understand the motivation for different programming paradigms: to abstract machine operation into human understandable and composable programs
· Understand the difference between syntax the textual symbols and grammatical rules of a program, and semantics the meaning of what is computed
· Understand that there are different models of computation upon which different programming languages are based, including machine models such as Turing Machines and von Neumann architecture, and the Lambda Calculus based on mathematical functions.
Syntax versus Semantics
As a branch of Computer Science, the theory and practice of programming has grown from a very practical need: to create tools to help us get computers to perform useful and often complex tasks. Programming languages are tools, that are designed and built by people to make life easier in this endeavour. Furthermore, they are rapidly evolving tools that have grown in subtlety and complexity over the many decades to take advantage of changing computer hardware and to take advantage of different ways to model computation.
An important distinction to make when considering different programming languages, is between syntax and semantics. The syntax of a programming language is the set of symbols and rules for combining them (the grammar) into a correctly structured program. These rules are often arbitrary and chosen for historical reasons, ease of implementation or even aesthetics. An example of a syntactic design choice is the use of indentation to denote block structure or symbols such as “BEGIN” and “END” or “{” and “}”.
Example: functions in python and C that are syntactically different, but semantically identical:
# python code
def sumTo(n):
sum = 0
for i in range(0,n):
sum = sum + i
return sum
// C code:
int sumTo(int n) {
int sum = 0;
for(int i = 0; i < n; i++) { sum += i; } return sum; } By contrast, the “semantics” of a programming language relate to the meaning of a program: how does it structure data? How does it execute or evaluate? In this course we will certainly be studying the syntax of the different languages we encounter. It is necessary to understand syntax in order to correctly compose programs that a compiler or interpreter can make sense of. The syntactic choices made by language designers are also often interesting in their own right and can have significant impact on the ease with which we can create or read programs. However, arguably the more profound learning outcome from this course should be an appreciation for the semantics of programming and how different languages lend themselves to fundamentally different approaches to programming, with different abstractions for modelling problems and different ways of executing and evaluating. Hence, we will be considering several languages that support quite different programming paradigms. For example, as we move forward we will see that C programs vary from the underlying machine language mostly syntactically. C abstracts certain details and particulars of the machine architecture and has much more efficient syntax than Assembly language, but the semantics of C are not so far removed from Assembler - especially modern assembler that supports procedures and conveniences for dealing with arrays. By contrast, Haskell and MiniZinc (which we will be exploring in the second half of this course) represent quite different paradigms where the underlying machine architecture, and even the mode of execution, is significantly abstracted away. MiniZinc, in particular, is completely declarative in the sense that the programmer’s job is to define and model the constraints of a problem. The approach to finding the solution, in fact any algorithmic details, are completely hidden. One other important concept that we try to convey in this course is that while some languages are engineered to support particular paradigms (such as functional programming or logic programming), the ideas can be brought to many different programming languages. For example, we begin learning about functional programming in JavaScript (actually TypeScript and EcmaScript 2017) and we will demonstrate that functional programming style is not only possible in this language, but brings with it a number of benefits. Later, we will pivot from JavaScript (briefly) to PureScript, a haskell-like language that compiles to JavaScript. We will see that, while PureScript syntax is very different to Javascript, the JavaScript generated by the PureScript compiler is not so different to the way we implemented functional paradigms manually in JavaScript. Then we will dive a little-more deeply into a language that more completely “buys into” the functional paradigm: Haskell. As well as having a syntax that makes functional programming very clean, the haskell compiler strictly enforces purity and makes the interesting choice of being lazy by default. In summary, the languages we will study (in varying degrees of depth) will be Assembler, C/C++, JavaScript (ES2017 and TypeScript), PureScript, Haskell and MiniZinc, with JavaScript/TypeScript and Haskell being the main languages explored in problem sets and assignments. Thus, this course will be a tour through programming paradigms that represent different levels of abstraction from the underlying machine architecture. To begin, we spend just a little time at the level of least abstraction: the hardware itself. The Machine Level Conceptually, modern computer architecture deviates little from the von Neumann model proposed in 1945 by Hungarian-American computer scientist John von Neumann. The development of the von Neumann model occurred shortly after the introduction of the theoretical Turing Machine concept. The von Neumann architecture was among the first to unify the concepts of data and programs. That is, in a von Neumann architecture, a program is just data that can be loaded into memory. A program is a list of instructions that read data from memory, manipulate it, and then write it back to memory. This is much more flexible than previous computer designs which had stored the programs separately in a fixed (read-only) manner. The classic von Neumann model looks like so: At a high-level, standard modern computer architecture still fits within this model: Programs run on an x86 machine according to the Instruction Execution Cycle: · CPU fetches instruction from instruction queue, increments instruction pointer · CPU decodes instruction and decides if it has operands · If necessary, CPU fetches operands from registers or memory · CPU executes the instruction · If necessary, CPU stores result, sets status flags, etc. Registers are locations on the CPU with very low-latency access due to their physical proximity to the execution engine. Modern x86 processors also have 2 or 3 levels of cache memory physically on-board the CPU. Accessing cache memory is slower than accessing registers (with all sorts of very complicated special cases) but still many times faster than accessing main memory. The CPU handles the movement of instructions and data between levels of cache memory and main memory automatically, cleverly and—for the most part—transparently. To cut a long story short, it can be very difficult to predict how long a particular memory access will take. Probably, accessing small amounts of memory repeatedly will be cached at a high-level and therefore fast. Other Models of Computation Turing Machines are a conceptual model of computation based on a physical analogy of tapes being written to and read from as they feed through a machine. The operations written on the tape determine the machine’s operation. The von Neumann model of computation has in common with Turing Machines that it follows an imperative paradigm of sequential instruction execution, but it is a practical model upon which most modern computers base their architecture. There are other models of computation that are also useful. In particular, we will look at the Lambda Calculus, which was roughly a contemporary of these other models but based on mathematical functions, their application and composition. We will see that while imperative programming languages are roughly abstractions of machine architecture, functional programming languages provide an alternative abstraction built upon the rules of the lambda calculus. Alternative Abstractions Humans think about programs in a different way to machines. Machines can read thousands or millions of instructions per second and execute them tirelessly and with precision. Humans need to understand programs at a higher level, and relate the elements of the program back to the semantics of the task and the ultimate goal. There is a clear and overwhelmingly agreed-upon need to create human-readable and writable languages which abstract away the details of the underlying computation into chunks that people can reason about. However, there are many ways to create these abstractions. Comparing the Dominant Programming Paradigms First some definitions which help to describe the different families of programming languages that we will be considering in this course. It is assumed that the reader already has experience with the first three paradigms (imperative, procedural and objected-oriented) since these are taught in most introductory programming courses. The rest are discussed further in later chapters in these notes. · Imperative programs are a sequence of statements that change a programs state. They follow the Turing machine model described above. This is probably the dominant paradigm for programming languages today. Languages from Assembler to Python are built around this concept and most modern languages still allow you to program in this style. · Procedural languages are basically imperative in nature, but add the concept of named procedures, i.e. named subroutines that may be invoked from elsewhere in the program, with parameterised variables that may be passed in. The result of the procedure may be returned as an explicit return value, or the procedure may mutate (change) the value of variables referenced elsewhere in the program (such a mutation is called a side effect). Again, most modern languages support definition of such procedures. Sometimes, the term function is used synonymously with procedure. Some languages (e.g. Pascal) make a distinction between procedures which mutate state without an explicit return value, while a function has an explicit return value. Note that the latter is closer to the definition of function in mathematics. · Object-oriented languages are built around the concept of objects where an objects captures the set of data (state) and behaviours (methods) associated with entities in the system. We assume most readers have already studied the basics of object oriented programming, such as defining classes of objects, inheritance and encapsulation. · Declarative languages focus on declaring what a procedure (or function) should do rather than how it should do it. Classic examples of declarative languages are SQL - which precisely describes a relational database query (i.e. what should be returned) without having to tell the database how the computation should be performed in (e.g. the sequence of steps to carry out to perform the query). HTML is also declarative: describing what a web page should look like without specifying how to render it. SQL and HTML both avoid defining the how by relying on an engine which already knows how to do the task (i.e. the database system (SQL) or the browser (HTML). By contrast, Prolog is an example of a language which is declarative but also a complete programming language (being able to perform any computation that a Turing machine can compute, i.e. Turing Complete). Declarative languages like Prolog manage to perform arbitrarily complex computations (e.g. with loops and evolving state) through recursive definitions. · Functional languages are built around the concept of composable functions. Such languages support higher order functions which can take other functions as arguments or return new functions as their result, following the rules of the Lambda Calculus (which we will explore in some depth later). Functional languages such as Haskell (which we are going to explore later) adhere closely to the mathematical definition of functions that are pure, i.e. that do not have side effects but whose only result is an explicit return value. Pure functional programs tend to be closer to a declarative definition of the solution since their manipulation of state is made explicit from the function parameter and return types rather than hidden in side effects (this is a quality which we will see through many examples later). Many modern languages support a mixture of functional (i.e. by supporting higher-order functions) and imperative style programming (by allowing mutable variables and side effects from functions). Until relatively recently there was a fairly clear distinction between languages which followed the Functional Programming (FP) paradigm versus the Object Oriented (OO) paradigm. From the 1990s to… well it still is… Object Oriented programming has been arguably the dominant paradigm. Programmers and system architects have found organising their programs and data into class hierarchies a natural way to model everything from simulations, to games, to business rules. But this focus on creating rigid structures around data is a static view of the world which becomes messy when dealing with dynamic state. Functional programming, however, focuses on functions as transformations of data. These two alternatives, Object-Oriented versus Functional, have been described as a Kingdom of Nouns versus a Kingdom of Verbs, respectively, where nouns are descriptions of data and verbs are functions. Historically these were seen as competing paradigms, leading to quite different languages such as C++ and Haskell. However, modern languages like TypeScript, Scala, C++17, Java >8, Swift, Rust, etc, provide facilities for both paradigms for you to use (or abuse) as you please.
Thus, these are no longer competing paradigms. Rather they are complementary, or at-least they can be depending on the skill of the programmer. They provide programmers with a choice of abstractions to apply as necessary to better manage complexity and achieve robust, reusable, scalable and maintainable code.
These notes focus on introducing programmers who are familiar with the OO paradigm to FP concepts via the ubiquitous multiparadigm language of JavaScript. The following table functions as a summary but also an overview of the contents of these notes with links to relevant sections.

Functional
Object-Oriented

Unit of Composition
Functions
Objects (classes)

Programming Style
Declarative
Imperative

Control Flow
Functions, recursion and chaining
Loops and conditionals

Polymorphism
Parametric
Sub-Typing

Data and Behaviour
Loosely coupled through pure, generic functions
Tightly coupled in classes with methods

State Management
Treats objects as immutable
Favours mutation of objects through instance methods

Thread Safety
Pure functions easily used concurrently
Can be difficult to manage

Encapsulation
Less essential
Needed to protect data integrity

Model of Computation
Lambda Calculus
Imperative (von Neumann/Turing)

JavaScript Introduction
Learning Outcomes
· Understand and use basic JavaScript coding concepts and features
· Understand the difference between mutable and immutable (const) variables
· Explain the relationship between javascript functions and objects
· Understand that the scope of variables is limited to delineated code blocks and within functions
· Understand that a closure captures variables referenced within its scope
· Create and apply anonymous functions to fluent style code
· Compare arrow functions and regular function syntax
· Explain JavaScript’s prototype mechanism for creating classes from functions
· Create ES6 style classes with constructors and getters
· Compare object oriented polymorphism to dependency injection through functions
Introduction
In the late 90s the mood was right for a language that was small and simple and with executable files small enough to be distributed over the web. Originally Java was meant to be that language but, while it quickly gained traction as a language for building general purpose applications and server-side middleware, it never really took off in the browser. Something even simpler, and better integrated with the Document Object Model (DOM) of HTML pages was required to add basic interaction to web pages.
Brendan Eich was hired by Netscape in 1995 to integrate a Scheme interpreter into their browser for this purpose. No messy deployment of Java bytecode bundles – the browser would have been able to run Scheme scripts embedded directly into web pages. This would have been awesome. Unfortunately, for reasons that were largely political and marketing related, it was felt that something more superficially resembling Java was required. Thus, Eich created a prototype scripting language in 2 weeks that eventually became JavaScript. As we will see, it is syntactically familiar for Java developers. Under the hood, however, it follows quite a different paradigm.
The fact it was initially rushed to market, the fact that browser makers seemingly had difficulty early on making standards-compliant implementations, and a couple of regrettable decisions at first regarding things like scoping semantics, meant that JavaScript developed something of a bad name. It’s also possible that there was some inherent snobbiness amongst computer science types that, since JavaScript was not a compiled language, it must inevitably lead to armageddon. Somehow, however, it survived and began the “web 2.0” phenomenon of what we now refer to as rich, client-side “web apps”. It has also matured and, with the EcmaScript 6 (ES6) and up versions, has actually become quite an elegant little multi paradigm language.
The following introduction to JavaScript assumes a reasonable knowledge of programming in another imperative language such as Python or Java.
Declaring Variables
We declare constant variables in JavaScript with the const keyword:
const z = 1 // constant (immutable variable) at global scope
You can try this in the debug console in a browser such as Chrome. If we try to change the value of such a const variable, we get a run-time error:
const z = 1
z = 2
Uncaught TypeError: Assignment to constant variable.
We define mutable variables in JavaScript with the let keyword:
let w = 1
console replies with the value returned by the let statement, which is:
undefined
but fear not, w was assigned the correct value which you can confirm by typing just w into the console:
w
1
Now if we assign a new value to w it succeeds:
w = 2 // note that without a let or const keyword before it, this assignment an expression which returns a value:
2
(Note: there is another legacy keyword for declaring variables in JavaScript var that has different scoping rules. Don’t use it.)
JavaScript Types
JavaScript has several “primitive types” (simple types that are not Objects). These include:
· number: any numeric value, integer or decimal
· string: delineated like “hello” or ‘hello’ or even `hello`.
· boolean: can be only true or false
· undefined: is a special type with only one value which is undefined.
and a couple of others that we won’t worry about here.
JavaScript is loosely typed in the sense that a mutable variable can be assigned (and re-assigned) different values of different types.
let x
undefined
x = 3
3
x = ‘hello’
“hello”
Variable scope
A variable’s scope is the region of the program where it is visible, i.e. it can be referenced. You can limit the scope of a variable by declaring it inside a block of code delineated by curly braces:
{
let x = 1
console.log(x)
}
Console prints 1 from the console.log:
1 But if we try to get the value of x:
x
Uncaught ReferenceError: x is not defined
The above console.log statement successfully output the value of x because it was inside the same scope (the same set of curly braces). The subsequent error occurs because we tried to look at x outside the scope of its definition. Variables declared outside of any scope are said to be “global” and will be visible to any code loaded on the same page and could clobber or be clobbered by other global definitions – so take care!
Be especially carefully to always declare variables with either let or const keywords. If you omit these keywords, a variable will be created at the global scope even though it is inside a { … } delimited scope, like so:
{
x = 1
}

x
1

We are going to start to use a few operators, that may be familiar from C or Java, some are JS specific.
Here’s a cheatsheet:
JavaScript 101: Basic Operator Cheat Sheet
Binary Operators
x % y // modulo
x == y // loose* equality
x != y // loose* inequality
x === y // strict+ equality
x !== y // strict+ inequality

a && b // logical and
a || b // logical or

a & b // bitwise and
a | b // bitwise or
* Loose (in)equality means type conversion may occur
+ Use strict (in)equality if type is expected to be same
Unary Operators
i++ // post-increment
++i // pre-increment
i– // post-decrement
–i // pre-decrement
!x // not x
Ternary Conditional Operator
? :
In-place math operators
x +=
// add result of expr to x
// also -=, *=, /=, |=, &=.
Functions
Functions are declared with the function keyword. You can give the function a name followed by a tuple of zero or more parameters. Variables declared within the function’s body (marked by a matching pair of curly braces { … }) are limited to the scope of that function body, but of course the parameters to the function are also in scope within the function body. You return the result with the return keyword.
/**
* define a function called “myFunction” with two parameters, x and y
* which does some silly math, prints the value and returns the result
*/
function myFunction(x, y) {
let t = x + y; // t is mutable
t += z; // += adds the result of the expression on the right to the value of t
const result = t // semi colons are not essential (but can help to catch errors)
console.log(“hello world”) // prints to the console
return result; // returns the result to the caller
}
You invoke (or ‘call’, or ‘apply’) a function like so:
myFunction(1,2)
hello world
4
An if-else statement looks like so:
/**
* get the greater of x and y
*/
function maxVal(x, y) {
if (x >= y) {
return x;
} else {
return y;
}
}
There is also a useful ternary expression syntax for if-then-else:
function maxVal(x, y) {
return x >= y ? x : y;
}
We can loop with while:
/**
* sum the numbers up to and including n
*/
function sumTo(n) {
let sum = 0;
while (n) { // when n is 0 this evaluates to false ending the loop
// add n to sum then decrement n
sum += n–; // see operator cheatsheet above
}
return sum;
}
sumTo(10)
55
Or for:
function sumTo(n) {
let sum = 0;
for (let i = 1; i <= n; i++) { sum += i; } return sum; } Or we could perform the same computation using a recursive loop: function sumTo(n) { if (n === 0) return 0; // base case return n + sumTo(n-1); // inductive step } We can make this really succinct with a ternary if-then-else expression: function sumTo(n) { return n ? n + sumTo(n-1) : 0; } We consider this recursive loop a more “declarative” coding style than the imperative loops. It is closer to the inductive definition of sum than a series of steps for how to compute it. · No mutable variables used · Each expression in this code is “pure”: it has no effects outside the expression. Thus, you could replace each element of code with something else that produces the same result for a given input (such as a simple look up of a precomputed cache) and it would work the same. · Therefore: this code has the property of referential transparency. · The code succinctly states the loop invariant. Stack Overflow and Tail Recursion Each time a function is invoked, the interpreter (or ultimately the CPU) will allocate another chunk of memory to a special area of memory set aside for such use called the stack. The stack is finite. A recursive function that calls itself too many times will consume all the available stack memory. Therefore, too many levels of recursion will cause a stack overflow. sumTo(1000000) Uncaught RangeError: Maximum call stack size exceeded However, functional languages (like Haskell) rely on recursion because they have no other way to create loops without mutable variables - so they must have a way to make this scale to real-world computations. When a recursive function is written in a special way, such that the recursive call is in tail position, compilers are able to transform the recursion into a while loop with constant memory use - this is called tail call optimisation. Let’s see what a tail recursive version of the sumTo function looks like: function sumTo(n, sum = 0) { return n ? sumTo(n-1, sum + n) : sum; } We have added a second parameter sum to store the computation as recursion proceeds. Such parameters are called accumulators. The = 0 in the parameter definition provides a default value in case the caller does not specify an argument. Thus, this new version can be called the same way as before: sumTo(10) 55 The important change is that the recursive call (on the branch of execution that requires it) is now the very last operation to be executed before the function returns. The computation (sum + n) occurs before the recursive call. Therefore, no local state needs to be stored on the stack. Note: although it has been proposed for the EcmaScript standard, as of 2020, not all JavaScript engines support tail call optimisation (only WebKit AFAIK). Functions as parameters to other functions We can make functions more versatile by parameterising them with other functions: function sumTo(n, f = x => x) {
return n ? f(n) + sumTo(n-1, f) : 0;
}
Note that the new parameter f defaults to a simple function that directly returns its argument. Thus, called without a second parameter sumTo has the same behavior as before:
sumTo(10)
55
But, we can now specify a non-trivial function to be applied to the numbers before they are summed. For example, a function to square a number:
function square(x) {
return x * x;
}
can be passed into sumTo to compute a sum of squares:
sumTo(10, square)
> 385
Objects
Like Java, everything in JavaScript is an object. You can construct an object populated with some data, essentially just with JSON syntax:
const myObj = {
aProperty: 123,
anotherProperty: “tim was here”
}
However, in JavaScript, objects are simply property bags, indexed by a hashtable:
// the following are equivalent and both involve a hashtable lookup:
console.log(myObj.aProperty)
console.log(myObj[‘aProperty’])
Note that when we declare an object with the const keyword as above, it is only weakly immutable. This means that we cannot reassign myObj to refer to a different object, however, we can change the properties inside myObj. Thus, the myObj variable is constant/immutable, but the object created by the declaration is mutable. So, after making the above const declaration, if we try the following reassignment of myObj we receive an error:
myObj = {
aProperty: 0,
anotherProperty: “tim wasn’t here”
}
VM48:1 Uncaught TypeError: Assignment to constant variable.
But the immutability due to const is weak or shallow in the sense that while the myObj variable which references the object is immutable, the properties of the object are mutable, i.e. we can reassign properties on myObj with no error:
myObj.aProperty = 0
We can also quickly declare variables that take the values of properties of an object, through destructuring syntax:
const {aProperty} = myObj
console.log(aProperty)
123
Which is equivalent to:
const aProperty = myObj.aProperty
This is most convenient to destructure objects passed as arguments to functions. It makes it clear from the function definition precisely which properties are going to be accessed. Consider:
const point = {x:123, y:456}
function showX({x}) {
console.log(x)
}
You can also initialise an object’s properties directly with variables. Unless a new property name is specified, the variable names become property names, like so:
const x = 123, tempY = 456
const point = {x /* variable name used as property name */,
y:tempY /* value from variable but new property name */}
point
{x: 123, y: 456}
Arrays
JavaScript has python-like syntax for array objects:
const a = [1,2,3]
a.length
3
a[0]
1
a[2]
3
You can also destructure arrays into local variables:
const [x,y,z] = a
z
3
Below, we see how Anonymous Functions can be applied to transform arrays, and a cheatsheet summary for further functions for working with arrays.
Dynamic Typing
The members of myObj are implicitly typed as number and string respectively, and as we see in the console.log, conversion to string happens automatically. JavaScript is interpreted by a JavaScript engine rather than compiled into a static executable format. Originally, this had implications on execution speed, as interpreting the program line by line at run time could be slow. Modern JavaScript engines, however, feature Just in Time (JIT) compilation and optimisation – and speed can sometimes be comparable to execution of C++ code that is compiled in advance to native machine code. However, another implication remains. It is not type checked by a compiler. Thus, type errors cause run-time failures rather than being caught at compile time. JavaScript is dynamically typed in that types are associated with values rather than variables. That is, a variable that is initially bound to one type, can later be rebound to a different type, e.g.:
let i = 123; // a numeric literal has type number
i = ‘a string’; // a string literal has type string, but no error here!
The C compiler would spit the dummy when trying to reassign i with a value of a different type, but the JavaScript interpreter is quite happy to go along with your decision to change your mind about the type of i.
Functions are Objects
The nifty thing about JavaScript – one Scheme’ish thing that presumably survived from Eich’s original plan – is that functions are also just objects. That is, given the following function:
function sayHello(person) {
console.log(‘hello ‘ + person)
}
sayHello(‘tim’)
“hello tim”
We can easily bind a function to a variable:
const hi = sayHello
hi(‘tim’)
“hello tim”
(Note: The original JavaScript syntax for declaring a variable used the var keyword. However, the scoping of variables declared in this way was strange for people familiar with C and Java scoping rules, and caused much angst. It has been fixed since ES6 with the let and const keywords, we prefer these to var.)
Anonymous Functions
The sayHello function is called a named function. We can also create an anonymous function to be bound immediately to a variable:
const hi = function(person) {
console.log(“hello ” + person)
}
or to pass as a parameter into another function, for example, Array objects have a forEach member that expects a function as an argument, which is then applied to every member of the array:
[‘tim’, ‘sally’, ‘anne’].forEach(function(person) {
console.log(‘hello ‘ + person)
})
“hello tim”
“hello sally”
“hello anne”
This pattern of passing functions as parameters to other functions is now so common in JavaScript that the EcmaScript 6 standard introduced some new arrow syntax (with slightly different semantics, as explained below) for anonymous functions:
[‘tim’, ‘sally’, ‘anne’].forEach(person=> console.log(‘hello ‘ + person))
Note that whatever value the expression on the right-hand side of the arrow evaluates to is implicitly returned:
[‘tim’, ‘sally’, ‘anne’].map(person=> “hello ” + person)
[“hello tim”, “hello sally”, “hello anne”]
Multiple statements (either split across lines or separated with ;s) including local variable declarations can be enclosed in brackets with arrow syntax, but then an explicit return statement is required to return a value:
[‘tim’, ‘sally’, ‘anne’].map(person=> {
const message = “hello ” + person
console.log(message)
return message
})
Arrow Functions
As mentioned above, ES6 introduced compact notation for anonymous functions:
const greeting = person=> ‘hello’ + person
Which is completely equivalent to the long form:
const greeting = function(person) {
return ‘hello ‘ + person
}
You can also have functions with a list of arguments, just put the list in brackets as for usual function definitions:
const greeting = (greeting, person)=> greeting + ‘ ‘ + person
The body of the above functions are simple expressions. If you need a more complex, multiline body (e.g. with local variables) you can do this but you need to surround the code block with curly braces {}:
const greeting = (greeting, person)=> {
const msg = greeting + ‘ ‘ + person
console.log(msg)
return msg
}
We can use multi-parameter anonymous functions with another nifty method on Array objects which allows us to reduce them to a single value.
[5,8,3,1,7,6,2].reduce((accumulator,x)=>accumulator+x,0)
32
The reduce method applies a function to each of the elements in the array, in order to compute an aggregated value for the whole array. The nature of the aggregate depends on the function you pass in. Here we just sum the elements in the array. The function we pass in has two parameters, the second is the array element (which we refer to here as x), the first parameter accumulator is either:
· the second argument to reduce (which in our case is 0), if this is the first call to the function,
· or, for every other call, the result returned by the previous call to the function.
reduce is incredibly versatile and can be used to do much more than sum numbers. For example, say we want to see whether all the elements of an array pass some test.
const all = (test, array) => array.reduce(
(accumulator, x) => accumulator && test(x),
true)
Here the accumulator is a boolean with initial value true. If an element of the array fails the test the accumulator becomes false and stays false, using the && operator.
all(x => x < 5, [1, 2, 3]) all(x => x < 5, [1, 3, 5]) true false Exercise · Can you write a function any that returns true if any of the tests pass? What if we wanted to see how many times each word appears in a list? const wordCount = (array) => array.reduce(
(accumulator, word) => {
if (accumulator[word]) {
accumulator[word] += 1
} else {
accumulator[word] = 1
}
return accumulator
},
{}
)
Here the accumulator is an object which is initially empty. For each word in the list the word count is either updated or created in the accumulator object. Note however that this implementation is not pure, the aggregator function modifies accumulator in place before returning it.
wordCount([‘tim’, ‘sally’, ‘tim’])
{ tim: 2, sally: 1 }
Array Cheatsheet
In the following, the annotations beginning with : after each parameter describe its type and again at the end of each function to describe its return type. The array a has elements of type U, and U=>V is the type of a function with input parameter type U and return type V (Note: these are not correct TS annotations, but an informal “shorthand”)
a.forEach(f: U=> void): void // apply the function f to each element of the array
Although it does not typically mutate a, forEach is impure if f has any side effect (which it most likely will because otherwise why would you bother!).
Pure Methods on Array
a.slice(): U[] // copy the whole array
a.slice(start: number): U[] // copy from the specified index to the end of the array
a.slice(start: number, // copy from start index up to
end: number): U[] // (but not including) end index
a.map(f: U=> V): V[] // apply f to elements of array
// and return result in new array of type V
a.filter(f: U=> boolean): U[] // returns a new array of the elements of a
// for which f returns true
a.concat(b: U[]): U[] // return a new array with the elements of b
// concatenated after the elements of a
a.concat(b: U[], c: U[]): U[] // return b and c appended to a.
// further arrays can be passed after c
a.reduce(f: (V, U)=> V, V): V // Uses f to combine elements of
// the array into a single result of type V
All of the above are pure in the sense that they do not mutate a, but return the result in a new object.
Note: the function passed to forEach takes an optional second parameter (not shown above) which is the index of the element being visited (see docs). While map, filter & reduce have a similar optional index parameter I suggest to avoid using it because it leads to hacky imperative style thinking about loops.
Closures
Functions can be nested inside other function definitions and can access variables from the enclosing scope.
Definitions:
· A function and the set of variables it accesses from its enclosing scope is called a closure.
· Variables from the enclosing scope that are accessed by the closure are said to be captured by the closure.
You can also have a function that creates and returns a closure that can be applied later:
function add(x) {
return y => y+x; // we are going to return a function which includes
// the variable x from it’s enclosing scope
// – “a closure”
}
let addNine = add(9)
addNine(10)
19
In the above example, the parameter x of the add function is captured by the anonymous function that is returned, which forms a closure. Thus, the binding of x to a value persists beyond the scope of the add function itself. Effectively, we have used the add function to create a new function: y=>y+9 – without actually writing the code ourselves.
addNine(1)
10
We can also call the add function with two arguments at once:
add(1)(2)
3
Compare to a more traditional function of two parameters:
function plus(x,y) { return x + y }
plus(1,2)
3
The add function above is a Curried version of the plus function.
As another example, consider a curried wrapper for our sumTo from before:
function sumOf(f) {
return n => sumTo(n, f)
}
Now, we can create custom functions that compute sums over arbitrary sequences:
const sumOfSquares = sumOf(square)
sumOfSquares(10)
385
sumOfSquares(20)
2870
Prototype Class Mechanism
Note: the following way to achieve class encapsulation is deprecated by ES6 syntax – skip to the next section to see the modern way to do it.
In JavaScript you can also create functions as members of objects:
let say = {
hello: person => console.log(‘hello ‘ + person)
}
say.hello(“tim”)
“hello tim”
But these objects are only single instances.
JavaScript supports creating object instances of a certain type (i.e. having a set of archetypical members, like a Java class) through a function prototype mechanism. You create a constructor function:
function Person(name, surname) {
this.name = name
this.surname = surname
}
let author = new Person(‘tim’, ‘dwyer’)
sayHello(author.name)
“hello tim”
You can also add method functions to the prototype, that are then available from any objects of that type:
Person.prototype.hello = function() { console.log(“hello ” + this.name) }
author.hello()
“hello tim”
Note that above we use the old-style verbose JavaScript anonymous function syntax instead of the arrow form. This is because there is a difference in the way the two different forms treat the this symbol. In the arrow syntax, this refers to the enclosing execution context. In the verbose syntax, this resolves to the object the method was called on.
It’s very tempting to use the prototype editing mechanism for evil. For example, I’ve always wished that JS had a function to create arrays initialised over a range:
Array.prototype.range =
(from, to)=>Array(to) // allocate space for an array of size `to`
.fill() // populate the array (with `undefined`s)
.map((_,i)=>i) // set each element of the array to its index
.filter(v=> v >= from) // filter out values below from

[].range(3,9)
[3,4,5,6,7,8]
Of course, if you do something like this in your JS library, and it pollutes the global namespace, and one day EcmaScript 9 introduces an actual range function with slightly different semantics, and someone else goes to use the [].range function expecting the official semantics – well, you may lose a friend or two.
Some notes about this implementation of range:
· Although the Array(n) function allocates space for n elements, the result is still “empty” so fill() is necessary to actually create the entries.
· The function passed to map is using an optional second argument which receives the index of the current element. See note in the Array Cheatsheat suggesting not to use this.
· The _ is not special syntax, it’s a valid variable name. I use _ as a convention for a parameter that I don’t use. This is imitating Haskell syntax.
EcmaScript 6 Class Syntax
Consider another class created with a function and a method added to the prototype:
function Person(name, occupation) {
this.name = name
this.occupation = occupation
}
Person.prototype.sayHello = function() {
console.log(`Hi, my name’s ${this.name} and I ${this.occupation}!`)
}
const tim = new Person(“Tim”,”lecture Programming Paradigms”)
tim.sayHello()
Hi, my name’s Tim and I lecture Programming Paradigms!
ES6 introduced a new syntax for classes that will be more familiar to Java programmers:
class Person {
constructor(name, occupation) {
this.name = name
this.occupation = occupation
}
sayHello() {
console.log(`Hi, my name’s ${this.name} and I ${this.occupation}!`)
}
}
There is also now syntax for “getter properties”: functions which can be invoked without (), i.e. to look more like properties:
class Person {
constructor(name, occupation) {
this.name = name
this.occupation = occupation
}
get greeting() {
return `Hi, my name’s ${this.name} and I ${this.occupation}!`
}
sayHello() {
console.log(this.greeting)
}
}
And classes of course support single-inheritance to achieve polymorphism:
class LoudPerson extends Person {
sayHello() {
console.log(this.greeting.toUpperCase())
}
}

const tims = [
new Person(“Tim”,”lecture Programming Paradigms”),
new LoudPerson(“Tim”,”shout about Programming Paradigms”)
]

tims.forEach(t => t.sayHello())
Hi, my name’s Tim and I lecture Programming Paradigms!
HI, MY NAME’S TIM AND I SHOUT ABOUT PROGRAMMING PARADIGMS!
Polymorphism
According to Cartelli et al., “Polymorphic types are types whose operations are applicable to values of more than one type.” Thus, although Person and LoudPerson are different types, since LoudPerson is a sub-type of Person, they present a common sayHello method allowing operations like forEach to operate over an array of the base class. In a traditional Object Oriented language like Java, the compiler enforces that objects must be instances of a common base class or interface to be treated as such. This type of polymorphism is called subtyping polymorphism.
In JavaScript, with no compile-time typecheck, a kind of polymorphism is possible such that if two objects both present a similarly named method that is callable in the same way, of course there is nothing preventing you simply using that method on each object as if it is the same:
const a = {f: ()=>console.log(“a”)}
const b = {f: ()=>console.log(“b”)}
[a,b].forEach(o=>o.f())
a
b
Informally, this type of polymorphism is called “Duck Typing” (i.e. “If it looks like a duck, swims like a duck, and quacks like a duck, then it probably is a duck”).
Another type of polymorphism which is key to strongly typed functional programming languages (like Haskell), but also a feature of many modern OO languages is parametric polymorphism. We will see this in action when we introduce TypeScript generics.
Reference: Cardelli, Luca, and Peter Wegner. “On understanding types, data abstraction, and polymorphism.” ACM Computing Surveys (CSUR) 17.4 (1985): 471-523.
Dependency Injection
It’s useful to compare the above style of polymorphism, to a functional approach to dependency injection:
class Person {
constructor(name, occupation, voiceTransform = g => g) {
this.name = name
this.occupation = occupation
this.voiceTransform = voiceTransform
}
get greeting() {
return `Hi, my name’s ${this.name} and I ${this.occupation}!`
}
sayHello() {
console.log(this.voiceTransform(this.greeting))
}
}
const tims = [
new Person(“Tim”, “lecture Programming Paradigms”),
new Person(“Tim”, “shout about Programming Paradigms”, g => g.toUpperCase())
]
tims.forEach(t => t.sayHello())
Hi, my name’s Tim and I lecture Programming Paradigms!
HI, MY NAME’S TIM AND I SHOUT ABOUT PROGRAMMING PARADIGMS!
So the filter property defaults to the identity function (a function which simply returns its argument), but a user of the Person class can inject a dependency on another function from outside the class when they construct an instance.
This is a “lighter-weight” style of code reuse or specialisation.
Functional Programming in JavaScript
Learning Outcomes
· Create programs in JavaScript in a functional style
· Understand the definitions of Function Purity and Referential Transparency
· Explain the role of pure functional programming style in managing side effects
· See how pure functions can be used to model sophisticated computation
Introduction
The elements of JavaScript covered in our introduction, specifically:
· Binding functions to variables
· Anonymous functions
· Higher-order functions
are sufficient for us to explore a paradigm called functional programming. In the functional programming paradigm the primary model of computation is through the evaluation of functions. Functional Programming is highly inspired by the Lambda Calculus, a theory which develops a model for computation based on application and evaluation of mathematical functions.
While JavaScript (and many—but not all, as we shall see—other languages inspired by the functional paradigm) do not enforce it, true functional programming mandates the functions be pure in the sense of not causing side effects.
Side Effects
Side effects of a function are changes to state outside of the result explicitly returned by the function.
Examples of side-effects from inside a function:
· changing the value of a variable declared outside the function scope
· mutating global state in this way can cause difficult-to-diagnose bugs: for example, an effective debugging strategy is dividing the program up into little pieces which can easily be proven correct or unit tested – sources of side-effects deep inside functions are a hidden form of coupling making such a strategy very difficult.
· printing to the console changing the state of the world in such a way can also be dangerous
· for example, filling a disk with log messages is a good way to crash the whole computer!
In languages without compilers that specifically guard against them, side effects can occur:
· intentionally through sloppy coding practices, where a misguided programmer may think it’s more convenient to have a function do multiple things at once;
· unintentionally, for example by accidentally setting a global variable instead of a local one.
We’ll see more examples in actual code below.
Function Purity and Referential Transparency
A pure function:
· has no side effects: i.e. it has no effects other than to create a return value;
· always produces the same result for the same input.
In the context of functional programming, referential transparency is:
· the property of being able to substitute an expression that evaluates to some value, with that value, without affecting the behaviour of the program.
Trivial Example
Imagine a simple function:
const square = x=>x*x
And some code that uses it:
const four = square(2)
The expression square(2) evaluates to 4. Can we replace the expression square(2) with the value 4 in the program above without changing the behaviour of the program? YES! So is the expression square(2) referentially transparent? YES!
But what if the square function depends on some other data stored somewhere in memory and may return a different result if that data mutates? (an example might be using a global variable or reading an environment variable from IO or requiring user input). What if square performs some other action instead of simply returning the result of a mathematical computation? What if it sends a message to the console or mutates a global variable? That is, what if it has side effects (is not a pure function)? In that case is replacing square(2) with the value 4 still going to leave our program behaving the same way? Possibly not!
Put another way, if the square function is not pure—i.e. it produces side effects (meaning it has hidden output other than its return value) or it is affected by side effects from other code (meaning it has hidden inputs)—then the expression square(2) would not be referentially transparent.
Realistic Examples
A real life example where this might be useful would be when a cached result for a given input already exists and can be returned without further computation. Imagine a pure function which computes PI to a specified number of decimal points precision. It takes an argument n, the number of decimal points, and returns the computed value. We could modify the function to instantly return a precomputed value for PI from a lookup table if n is less than 10. This substitution is trivial and is guaranteed not to break our program, because its effects are strictly locally contained.
Pure functions and referential transparency are perhaps most easily illustrated with some examples and counterexamples. Consider the following impure function:
function impureSquares(a) {
let i = 0
while (i < a.length) { * a[i] = a[i] * a[i++]; } } Since the function modifies a in place we get a different outcome if we call it more than once. const myArray=[1,2,3] impureSquares(myArray) // now myArray = [2,4,9] impureSquares(myArray) // now myArray = [4,16,81] Furthermore, the very imperative style computation in impureSquares at the line marked with * is not pure. It has two effects: incrementing i and mutating a. You could not simply replace the expression with the value computed by the expression and have the program work in the same way. This piece of code does not have the property of referential transparency. True pure functional languages (such as Haskell) enforce referential transparency through immutable variables (note: yes, “immutable variable” sounds like an oxymoron - two words with opposite meanings put together). That is, once any variable in such a language is bound to a value, it cannot be reassigned. In JavaScript we can opt-in to immutable variables by declaring them const, but it is only a shallow immutability. Thus, the variable myArray above, cannot be reassigned to reference a different array. However, we can change the contents of the array as shown above. A more functional way to implement the squares function would be more like the examples we have seen previously: function squares(a) { return a.map(x=> x*x)
}
The above function is pure. Its result is a new array containing the squares of the input array and the input array itself is unchanged. It has no side effects changing values of variables, memory or the world, outside of its own scope. You could replace the computation of the result with a different calculation returning the same result for a given input and the program would be unchanged. It is referentially transparent.
const myArray = [1,2,3]
const mySquares = squares(myArray)
const myRaisedToTheFours = squares(mySquares)
We could make the following substitution in the last line with no unintended consequences:
const myRaisedToTheFours = squares(squares(myArray))
An impure function typical of something you may see in OO code:
let messagesSent = 0;
function send(message, recipient) {
let success = recipient.notify(message);
if (success) {
++messagesSent;
} else {
console.log(“send failed! ” + message);
}
console.log(“messages sent ” + messagesSent);
}
This function is impure in three ways:
· it mutates the state of the count variable messagesSent from the enclosing scope
· it (likely) does something (what exactly is unclear) to recipient
· finally, it sends output to the console. Outputting to a device (although only for display purposes) is definitely a side effect.
Side effects are bad for transparency (knowing everything about what a function is going to do) and maintainability. When state in your program is being changed from all over the place bugs become very difficult to track down.
Functional Patterns
Passing functions around, anonymous or not, is incredibly useful and pops up in many practical programming situations.
Eliminating Loops
Loops are the source of many bugs: fence-post errors, range errors, typos, incrementing the wrong counter, etc.
A typical for loop has four distinct places where it’s easy to make errors that can cause critical problems:
for ([initialization]; [condition]; [final-expression])
statement
· The initialization can initialise to the wrong value (e.g. n instead of n-1, 1 instead of 0) or initialise the wrong variable.
· The condition test can use = instead of ==, <= instead of < or test the wrong variable, etc. · The final-expression can (again) increment the wrong variable · The statement body might change the state of variables being tested in the termination condition since they are in scope. For many standard loops, however, the logic is the same every time and can easily be abstracted into a function. Examples: Array.map, Array.reduce, Array.forEach, etc. The logic of the loop body is specified with a function which can execute in its own scope, without the risk of breaking the loop logic. Callbacks In JavaScript and HTML5 events trigger actions associated with all mouse clicks and other interactions with the page. You subscribe to an event on a given HTML element as follows: element.addEventHandler('click', e=>{
// do something when the event occurs,
// maybe using the result of the event e
})
Note that callback functions passed as event handlers are a situation where the one semantic difference between the arrow syntax and regular anonymous function syntax really matters. In the body of the arrow function above, this will be bound to the context of the caller, which is probably what you want if you are coding a class for a reusable component. For functions defined with the function keyword the object that this refers to will depend on the context of the callee, although the precise behaviour of this for functions defined with function may vary with the particular JavaScript engine and the mode of execution.
Here’s a situation where this makes a difference. Recall that JavaScript functions are just objects. Therefore, we can also assign properties to them. We can do this from within the function itself using the this keyword:
function Counter() {
this.count = 0;
setInterval(function increment() {
console.log(this.count++)
}, 500);
}
const ctr = new Counter();
But, if I run this program at a console, I get the following, each line emitted 500 milliseconds apart:
NaN
NaN
NaN
…
This occurs because the this inside the function passed to setInterval is referring to the first function enclosing its scope, i.e. the increment function. Since increment has no count property, we are trying to apply ++ to undefined and the result is NaN (Not a Number).
Arrow functions have different scoping rules for this. That is, they take the this of the enclosing scope (outside the arrow function), so in the following we get the expected behaviour:
function Counter() {
this.count = 0;
setInterval(()=>console.log(this.count++), 500);
}
new Counter();
0
1 2
…
Continuations
Continuations are functions which, instead of returning the result of a computation directly to the caller, pass the result on to another function, specified by the caller.
We can rewrite basically any function to pass their result to a user-specified continuation function instead of returning the result directly. The parameter done in the ` continuationPlus` function below will be a function specified by the caller to do something with the result.
function simplePlus(a, b) {
return a + b;
}
function continuationPlus(a, b, done) {
done(a+b);
}
We can also rewrite tail-recursive functions to end with continuations, which specify some custom action to perform when the recursion is complete:
function tailRecFactorial(a, n) {
return n<=1 ? a : tailRecFactorial(n*a, n-1); } function continuationFactorial( a, n, finalAction=(result)=>{})
{
if (n<=1) finalAction(a); else continuationFactorial(n*a, n-1, finalAction); } Continuations are essential in asynchronous processing, which abounds in web programming. For example, when an HTTP request is dispatched by a client to a server, there is no knowing precisely when the response will be returned (it depends on the speed of the server, the network between client and server, and load on that network). However, we can be sure that it will not be instant and certainly not before the line of code following the dispatch is executed by the interpreter. Thus, continuation style call-back functions are typically passed through to functions which trigger such asynchronous behaviour, for those call-back functions to be invoked when the action is completed. A simple example of an asynchronous function invocation is the built-in setTimeout function, which schedules an action to occur after a certain delay. The setTimeout function itself returns immediately after dispatching the job, e.g. to the JavaScript event loop: setTimeout(()=>console.log(‘done.’), 0);
// the above tells the event loop to execute
// the continuation after 0 milliseconds delay.
// even with a zero-length delay, the synchronous code
// after the setTimeout will be run first…
console.log(‘job queued on the event loop…’);
job queued on the event loop…
done.
Function and Method Chaining
Chained functions are a common pattern.
Take a simple linked-list data structure as an example. We’ll hard code a list object to start off with:
const l = {
data: 1,
next: {
data: 2,
next: {
data: 3,
next: null
}
}
}
We can create simple functions similar to those of Array, which we can chain:
const
map = (f,l) => l ? ({data: f(l.data), next: map(f,l.next)}) : null
, filter = (f,l) => !l ? null :
(next =>
f(l.data) ? ({data: l.data, next})
: next
) (filter(f,l.next))
// the above is using an IIFE such that
// the function parameter `next` is used
// like a local variable for filter(f,l.next)
, take = (n,l) => l && n ? ({data: l.data, next: take(n-1,l.next)})
: null
We can chain calls to these functions like so:
take(2,
filter(x=> x%2 === 0,
map(x=> x+1, l)
)
)
{ data: 2, next: { data: 4, next: null }}
Fluent Interfaces (pure vs impure)
In the chained function calls above you have to read them inside-out to understand the flow. Also, keeping track of how many brackets to close gets a bit annoying. Thus, in object oriented languages you will often see class definitions that allow for method chaining, by providing methods that return an instance of the class itself, or another chainable class.
class List {
constructor(private head) {}
map(f) {
return new List(map(f, this.head));
}
…
Then the same flow as above is possible without the nesting and can be read left-to-right, top-to-bottom:
new List(l)
.map(x=>x+1)
.filter(x=>x%2===0)
.take(2)
This is called fluent programming style. Interfaces in object-oriented languages that chain a sequence of method calls (as above) are often called fluent interfaces. One thing to be careful about fluent interfaces in languages that do not enforce purity is that the methods may or may not be pure.
That is, the type system does not warn you whether the method mutates the object upon which it is invoked and simply returns this, or creates a new object, leaving the original object untouched. We can see, however, that List.map as defined above, creates a new list and is pure.
Computation with Pure Functions
Pure functions may seem restrictive, but in fact pure function expressions and higher-order functions can be combined into powerful programs. In fact, anything you can compute with an imperative program can be computed through function composition. Side effects are required eventually, but they can be managed and the places they occur can be isolated. Let’s do a little demonstration, although it might be a bit impractical, we’ll make a little list processing environment with just functions:
const cons = (_head, _rest)=> selector=> selector(_head, _rest);
With just the above definition we can construct a list (the term cons dates back to LISP) with three elements, terminated with null, like so:
const list123 = cons(1, cons(2, cons(3, null)));
The data element, and the reference to the next node in the list are stored in the closure returned by the cons function. Created like this, the only side-effect of growing the list is creation of new cons closures. Mutation of more complex structures such as trees can be managed in a similarly ‘pure’ way, and surprisingly efficiently, as we will see later in this course.
So cons is a function that takes two parameters _head and _rest (the _ prefix is just to differentiate them from the functions I create below), and returns a function that itself takes a function (selector) as argument. The selector function is then applied to _head and _rest.
The selector function that we pass to the list is our ticket to accessing its elements:
list123((_head, _rest)=> _head)
1
list123((_,r)=>r)((h,_)=>h) // we can call the parameters whatever we like
2
We can create accessor functions to operate on a given list (by passing the list the appropriate selector function):
const
head = list=> list((h,_)=>h),
rest = list=> list((_,r)=>r)
Now, head gives us the first data element from the list, and rest gives us another list. Now we can access things in the list like so:
const one = head(list123), // ===1
list23 = rest(list123),
two = head(list23), // ===2
… // and so on
Now, here’s the ubiquitous map function:
const map = (f, list)=> !list ? null
: cons(f(head(list)), map(f, rest(list)))
In the above, we are using closures to store data. It’s just a trick to show the power of functions and to put us into the right state of mind for the Lambda Calculus – which provides a complete model of computation using only anonymous functions like those above. In a real program I would expect you would use JavaScript’s class and object facilities to create data structures.
Towards Lambda Calculus and Church Encoding
Thus, with only pure function expressions and JavaScript conditional expressions (?:) we can begin to perform complex computations. We can actually go further and eliminate the conditional expressions with more functions! Here’s the gist of it: we wrap list nodes with another function of two arguments, one argument, whenempty, is a function to apply when the list is empty, the other argument, notempty, is applied by all internal nodes in the list. An empty list node (instead of null) applies the whenempty function when visited, a non-empty node applies the notempty function. The implementations of each of these functions then form the two conditions to be handled by a recursive algorithm like map or reduce. See “Making Data out of Functions” by Braithwaite for a more detailed exposition of this idea.
These ideas, of computation through pure function expressions, are inspired by Alonzo Church’s lambda calculus. We’ll be looking again at the lambda calculus later. Obviously, for the program to be at all useful you will need some sort of side effect, such as outputting the results of a computation to a display device. When we begin to explore PureScript and Haskell later in this course we will discuss how such languages manage this trick while remaining “pure”.
Updating Data Structures With Pure Functions
We saw in the introduction to JavaScript that one can create objects with a straightforward chunk of JSON:
const studentVersion1 = {
name: “Tim”,
assignmentMark: 20,
examMark: 15
}
studentVersion1
{name: “Tim”, assignmentMark: 20, examMark: 15}
Conveniently, one can copy all of the properties from an existing object into a new object using the “spread” operator …, followed by more JSON properties that can potentially overwrite those of the original. For example, the following creates a new object with all the properties of the first, but with a different assignmentMark:
const studentVersion2 = {
…studentVersion1,
assignmentMark: 19
}
studentVersion2
{name: “Tim”, assignmentMark: 19, examMark: 15}
One can encapsulate such updates in a succinct pure function:
function updateExamMark(student, newMark) {
return {…student, examMark: newMark}
}

function curry(f:(x:U,y:V)=>W): CurriedFunc {
return x=>y=>f(x,y)
}
Why should we declare types?
Declaring types for variables, functions and their parameters, and so on, provides more information to the person reading and using the code, but also to the compiler, which will check that you are using them consistently and correctly. This prevents a lot of errors.
Consider that JavaScript is commonly used to manipulate HTML pages. For example, I can get the top level headings in the current page, like so:
const headings = document.getElementsByTagName(“h1”)
In the browser, the global document variable always points to the currently loaded HTML document. Its method getElementsByTagName returns a collection of elements with the specified tag, in this case

join(f(value), g(value));
}
But we’ll leave trying it out as an exercise.

Fork-Join Exercise
· Use the fork-join combinator to compute the average over a sequence of numeric values.
· Add Type annotations to the above definition of the fork function. How many distinct type variables do you need?

End Note
Unary versus Binary Functions in JavaScript
Uncurried functions of two parameters can be called Binary functions. Functions of only one parameter can therefore be called Unary functions. Note that all of our curried functions are unary functions, which return other unary functions. We’ve seen situations now where curried functions are flexibly combined to be used in different situations.
Note that in JavaScript you sometimes see casual calls to binary functions but with only one parameter specified. Inside the called function the unspecified parameter will simply be undefined which is fine if the case of that parameter being undefined is handled in a way that does not cause an error or unexpected results, e.g.:
function binaryFunc(x,y) {console.log(`${x} ${y}`) }
binaryFunc(“Hello”, “World”)
binaryFunc(“Hello”)
Hello World
Hello undefined
Conversely, javascript allows additional parameters to be passed to unary functions which will then simply be unused, e.g.:
function unaryFunc(x) { console.log(x) }
unaryFunc(“Hello”)
unaryFunc(“Hello”, “World”)
Hello
Hello
But, here’s an interesting example where mixing up unary and binary functions in JavaScript’s very forgiving environment can go wrong.
[‘1′,’2′,’3’].map(parseInt);
We are converting an array of strings into an array of int. The output will be [1,2,3] right? WRONG!
[‘1′,’2′,’3’].map(parseInt);
[1, NaN, NaN]
What the …!
But:
parseInt(‘2’)
2
What’s going on? HINT: parseInt is not actually a unary function.
The point of this demonstration is that curried functions are a more principled way to support partial function application, and also much safer and easier to use when the types guard against improper use. Thus, this is about as sophisticated as we are going to try to get with Functional Programming in JavaScript, and we will pick up our discussion further exploring the power of FP in the context of the Haskell functional programming language. However, libraries do exist that provide quite flexible functional programming abstractions in JavaScript. For example, you might like to investigate Ramda.

Related Posts