\PassOptionsToPackage{unicode=true}{hyperref} % options for packages loaded elsewhere
\PassOptionsToPackage{hyphens}{url}
%
\documentclass[]{article}
\usepackage{lmodern}
\usepackage{amssymb,amsmath}
\usepackage{ifxetex,ifluatex}
\usepackage{fixltx2e} % provides \textsubscript
\ifnum 0\ifxetex 1\fi\ifluatex 1\fi=0 % if pdftex
  \usepackage[T1]{fontenc}
  \usepackage[utf8]{inputenc}
  \usepackage{textcomp} % provides euro and other symbols
\else % if luatex or xelatex
  \usepackage{unicode-math}
  \defaultfontfeatures{Ligatures=TeX,Scale=MatchLowercase}
\fi
% use upquote if available, for straight quotes in verbatim environments
\IfFileExists{upquote.sty}{\usepackage{upquote}}{}
% use microtype if available
\IfFileExists{microtype.sty}{%
\usepackage[]{microtype}
\UseMicrotypeSet[protrusion]{basicmath} % disable protrusion for tt fonts
}{}
\IfFileExists{parskip.sty}{%
\usepackage{parskip}
}{% else
\setlength{\parindent}{0pt}
\setlength{\parskip}{6pt plus 2pt minus 1pt}
}
\usepackage{hyperref}
\hypersetup{
            pdftitle={CSci 658: Software Language Engineering Programming Paradigms},
            pdfauthor={H. Conrad Cunningham},
            pdfborder={0 0 0},
            breaklinks=true}
\urlstyle{same}  % don't use monospace font for urls
\usepackage{color}
\usepackage{fancyvrb}
\newcommand{\VerbBar}{|}
\newcommand{\VERB}{\Verb[commandchars=\\\{\}]}
\DefineVerbatimEnvironment{Highlighting}{Verbatim}{commandchars=\\\{\}}
% Add ',fontsize=\small' for more characters per line
\newenvironment{Shaded}{}{}
\newcommand{\AlertTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
\newcommand{\AnnotationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\AttributeTok}[1]{\textcolor[rgb]{0.49,0.56,0.16}{#1}}
\newcommand{\BaseNTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\BuiltInTok}[1]{#1}
\newcommand{\CharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\CommentTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textit{#1}}}
\newcommand{\CommentVarTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\ConstantTok}[1]{\textcolor[rgb]{0.53,0.00,0.00}{#1}}
\newcommand{\ControlFlowTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
\newcommand{\DataTypeTok}[1]{\textcolor[rgb]{0.56,0.13,0.00}{#1}}
\newcommand{\DecValTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\DocumentationTok}[1]{\textcolor[rgb]{0.73,0.13,0.13}{\textit{#1}}}
\newcommand{\ErrorTok}[1]{\textcolor[rgb]{1.00,0.00,0.00}{\textbf{#1}}}
\newcommand{\ExtensionTok}[1]{#1}
\newcommand{\FloatTok}[1]{\textcolor[rgb]{0.25,0.63,0.44}{#1}}
\newcommand{\FunctionTok}[1]{\textcolor[rgb]{0.02,0.16,0.49}{#1}}
\newcommand{\ImportTok}[1]{#1}
\newcommand{\InformationTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\newcommand{\KeywordTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{\textbf{#1}}}
\newcommand{\NormalTok}[1]{#1}
\newcommand{\OperatorTok}[1]{\textcolor[rgb]{0.40,0.40,0.40}{#1}}
\newcommand{\OtherTok}[1]{\textcolor[rgb]{0.00,0.44,0.13}{#1}}
\newcommand{\PreprocessorTok}[1]{\textcolor[rgb]{0.74,0.48,0.00}{#1}}
\newcommand{\RegionMarkerTok}[1]{#1}
\newcommand{\SpecialCharTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\SpecialStringTok}[1]{\textcolor[rgb]{0.73,0.40,0.53}{#1}}
\newcommand{\StringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\VariableTok}[1]{\textcolor[rgb]{0.10,0.09,0.49}{#1}}
\newcommand{\VerbatimStringTok}[1]{\textcolor[rgb]{0.25,0.44,0.63}{#1}}
\newcommand{\WarningTok}[1]{\textcolor[rgb]{0.38,0.63,0.69}{\textbf{\textit{#1}}}}
\setlength{\emergencystretch}{3em}  % prevent overfull lines
\providecommand{\tightlist}{%
  \setlength{\itemsep}{0pt}\setlength{\parskip}{0pt}}
\setcounter{secnumdepth}{0}
% Redefines (sub)paragraphs to behave more like sections
\ifx\paragraph\undefined\else
\let\oldparagraph\paragraph
\renewcommand{\paragraph}[1]{\oldparagraph{#1}\mbox{}}
\fi
\ifx\subparagraph\undefined\else
\let\oldsubparagraph\subparagraph
\renewcommand{\subparagraph}[1]{\oldsubparagraph{#1}\mbox{}}
\fi

% set default figure placement to htbp
\makeatletter
\def\fps@figure{htbp}
\makeatother

\usepackage{caption}
\DeclareCaptionLabelFormat{nolabel}{}
\captionsetup{labelformat=nolabel}

\title{CSci 658: Software Language Engineering\\
Programming Paradigms}
\author{\textbf{H. Conrad Cunningham}}
\date{\textbf{17 February 2018}}

\begin{document}
\maketitle

{
\setcounter{tocdepth}{4}
\tableofcontents
}
Copyright (C) 2016, 2017, 2018, \href{http://www.cs.olemiss.edu/~hcc}{H.
Conrad Cunningham}\\
Professor of \href{https://www.cs.olemiss.edu}{Computer and Information
Science}\\
\href{http://www.olemiss.edu}{University of Mississippi}\\
211 Weir Hall\\
P.O. Box 1848\\
University, MS 38677\\
(662) 915-5358

\textbf{Advisory}: The HTML version of this document may require use of
a browser that supports the display of MathML. A good choice as of
February 2018 is a recent version of Firefox from Mozilla.

\hypertarget{programming-paradigms}{%
\section{Programming Paradigms}\label{programming-paradigms}}

\hypertarget{introduction}{%
\subsection{Introduction}\label{introduction}}

TODO: Add text and objectives

\hypertarget{primary-programming-paradigms}{%
\subsection{Primary Programming
Paradigms}\label{primary-programming-paradigms}}

According to Timothy Budd, a \emph{programming paradigm} is ``a way of
conceptualizing what it means to perform computation, of structuring and
organizing how tasks are to be carried out on a computer'' {[}Budd 1995
(p.~3){]}.

Historically, computer scientists have classified programming
\emph{languages} into one of two primary paradigms: \emph{imperative}
and \emph{declarative}.

In recent years, many imperative languages have added more declarative
features, so the distinction between languages has become blurred.
However, the concept of \emph{programming} paradigm is still meaningful.

\hypertarget{imperative-paradigm}{%
\subsubsection{Imperative paradigm}\label{imperative-paradigm}}

A program in the imperative paradigm has an \emph{implicit state} (i.e.,
values of variables, program counters, etc.) that is modified (i.e.,
side-effected or mutated) by \emph{constructs} (i.e., commands) in the
source language {[}Hudak 1989{]}.

As a result, such languages generally have an explicit notion of
\emph{sequencing} (of the commands) to permit precise and deterministic
control of the state changes.

Imperative programs thus express \emph{how} something is to be computed.

Consider the following fragment of Java code:

\begin{Shaded}
\begin{Highlighting}[]
    \DataTypeTok{int}\NormalTok{ count =  }\DecValTok{0}\NormalTok{;}
    \DataTypeTok{int}\NormalTok{ maxc  = }\DecValTok{10}\NormalTok{;}
    \KeywordTok{while}\NormalTok{ (count <= maxc) \{}
        \BuiltInTok{System}\NormalTok{.}\FunctionTok{out}\NormalTok{.}\FunctionTok{println}\NormalTok{(count) ;}
\NormalTok{        count = count + }\DecValTok{1}
\NormalTok{    \}}
\end{Highlighting}
\end{Shaded}

In this fragment, the program's \emph{state} includes at least the
values of the variables \texttt{count} and \texttt{maxc}, the sequence
of output lines that have been printed, and an indicator of which
statement to execute next (i.e., location or program counter).

The assignment statement changes the value of \texttt{count} and the
\texttt{println} statement adds a new line to the output sequence. These
are \emph{side effects} of the execution.

Similarly, Java executes these commands in sequence, causing a change in
which statement will be executed next. The purpose of the \texttt{while}
statement is to cause the statements between the braces to be executed
zero or more times. The number of times depends upon the values of
\texttt{count} and \texttt{maxc} and how the values change within the
\texttt{while} loop.

We call this state \emph{implicit} because the aspects of the state used
by a particular statement are not explicitly specified; the state is
assumed from the context of the statement. Sometimes a statement can
modify aspects of the state that are not evident from examining the code
fragment itself.

The Java variable \texttt{count} is \emph{mutable} because its value can
change. After the declaration, \texttt{count} has the value 0. At the
end of the first iteration of the \texttt{while} loop, it has value 1.
After the \texttt{while} loop exits, it has a value 10. So a reference
to \texttt{count} yields different values depending upon the state of
the program at that point.

The Java variable \texttt{maxc} is also \emph{mutable}, but this code
fragment does not change its value.

Imperative languages are the ``conventional'' or ``von Neumann
languages'' discussed by John Backus in his 1977 Turing Award address
{[}Backus 1978{]}. (See the section with excerpts from that address.)
They are well suited to traditional computer architectures.

Most of the languages in existence today are primarily imperative in
nature. These include Fortran, C, C++, Java, C\#, Python, Lua, and
JavaScript.

\hypertarget{declarative-paradigm}{%
\subsubsection{Declarative paradigm}\label{declarative-paradigm}}

A program in the declarative paradigm has \emph{no implicit} state. Any
needed state information must be handled explicitly {[}Hudak 1989{]}.

A program is made up of \emph{expressions} (or terms) that are
\emph{evaluated} rather than commands that are executed.

Repetitive execution is accomplished by \emph{recursion} rather than by
sequencing.

Declarative programs express \emph{what} is to be computed (rather than
how it is to be computed).

The declarative paradigm is often divided into two types:
\emph{functional} (or applicative) and \emph{relational} (or logic).

\hypertarget{functional-paradigm}{%
\paragraph{Functional paradigm}\label{functional-paradigm}}

TODO: Perhaps introduce IO program for printing result of counter.

In the functional paradigm the underlying model of computation is the
mathematical concept of a \emph{function}.

In a computation, a function is applied to zero or more arguments to
compute a single result; that is, the result is deterministic (or
predictable).

Consider the following Haskell code. (Don't worry about the details of
the language for now. We study the syntax and semantics of Haskell in an
upcoming chapter.)

\begin{Shaded}
\begin{Highlighting}[]
\OtherTok{    counter ::} \DataTypeTok{Int} \OtherTok{->} \DataTypeTok{Int} \OtherTok{->} \DataTypeTok{String} 
\NormalTok{    counter count maxc }
        \FunctionTok{|}\NormalTok{ count }\FunctionTok{<=}\NormalTok{ maxc }\FunctionTok{=}\NormalTok{ show count }\FunctionTok{++} \StringTok{"\textbackslash{}n"} \FunctionTok{++}\NormalTok{ counter (count}\FunctionTok{+}\DecValTok{1}\NormalTok{) maxc }
        \FunctionTok{|}\NormalTok{ otherwise     }\FunctionTok{=} \StringTok{""}
\end{Highlighting}
\end{Shaded}

This fragment is similar to the Java fragment above. This Haskell code
defines a function \texttt{counter} that takes two integer arguments,
\texttt{count} and \texttt{maxc}, and returns a string consisting of a
sequence of lines with the integers from \texttt{count} to \texttt{maxc}
such that each would be printed on a separate line. (It does not print
the string, but it inserts newline character at the end of each line.)

In the execution of a function call, \texttt{counter} references the
\emph{values} of \texttt{count} and \texttt{maxc} corresponding to the
explicit arguments of the function call. These values are not changed
within the execution of that function call. However, the values of the
arguments can be changed as needed for a subsequent \emph{recursive}
call of \texttt{counter}.

We call the state of \texttt{counter} \emph{explicit} because it is
passed in arguments of the function call. These parameters are
\emph{immutable} (i.e., their values cannot change) within the body of
the function. That is, any reference to \texttt{count} or \texttt{maxc}
within a call gets the same value.

In a pure functional language like Haskell, the names like
\texttt{count} and \texttt{maxc} are said to be \emph{referentially
transparent}. In the same context (such as the body of the function),
they always have the same value. A name must be defined before it is
used, but otherwise the order of the execution of the expressions within
a function body does not matter.

There are no ``loops''. The functional paradigm uses recursive calls to
carry out a task repeatedly.

In most programming languages that support functional programming,
functions are treated as \emph{first class} values. That is, like other
data types, functions can be stored in data structures, passed as
arguments to functions, and returned as the results of functions. (The
implementation technique for first-order functions usually involves
creation of a \emph{lexical closure} holding the function and its
environment.)

A function that can take functions as arguments or return functions in
the result is called a \emph{higher-order function}. A function that
does not take or return functions is thus a \emph{first-order function}.
Most imperative languages do not fully support higher-order functions.

The higher-order functions in functional programming languages enable
regular and powerful abstractions and operations to be constructed. By
taking advantage of a library of higher-order functions that capture
common patterns of computation, we can quickly construct concise, yet
powerful, programs.

Purely functional languages include Haskell, Idris, Miranda, Hope, Elm,
and Backus' FP.

Hybrid functional languages with significant functional subsets include
Scala, F\#, OCaml, SML, Erlang, Elixir, Lisp, Clojure, and Scheme.

Mainstream imperative languages such as Java (beginning with version 8),
C\#, Python, Ruby, Groovy, Rust, and Swift have recent feature
extensions that make them hybrid languages as well.

\hypertarget{relational-or-logic-paradigm}{%
\paragraph{Relational (or logic)
paradigm}\label{relational-or-logic-paradigm}}

In the relational (logic) paradigm, the underlying model of computation
is the mathematical concept of a \emph{relation} (or a \emph{predicate})
{[}Hudak 1989{]}.

A computation is the (nondeterministic) association of a group of
values---with backtracking to resolve additional values.

Consider the following SWI-Prolog code. (Don't worry about the details
of the language.)

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    counter(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\DataTypeTok{S}\NormalTok{) }\KeywordTok{:-}\NormalTok{ count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\DataTypeTok{R}\NormalTok{)}\KeywordTok{,}\NormalTok{ atomics_to_string(}\DataTypeTok{R}\KeywordTok{,}\StringTok{'}\CharTok{\textbackslash{}n}\StringTok{'}\KeywordTok{,}\DataTypeTok{S}\NormalTok{)}\KeywordTok{.}

\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{X}\KeywordTok{,}\NormalTok{[}\DataTypeTok{X}\NormalTok{])}\KeywordTok{.} 
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\NormalTok{[])     }\KeywordTok{:-} \DataTypeTok{X}  \DataTypeTok{>} \DataTypeTok{Y}\KeywordTok{.} 
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\NormalTok{[}\DataTypeTok{X}\FunctionTok{|}\DataTypeTok{Rs}\NormalTok{]) }\KeywordTok{:-} \DataTypeTok{X} \DataTypeTok{<} \DataTypeTok{Y}\KeywordTok{,} \DataTypeTok{NX} \DataTypeTok{is} \DataTypeTok{X+}\DecValTok{1}\KeywordTok{,}\NormalTok{ count(}\DataTypeTok{NX}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\DataTypeTok{Rs}\NormalTok{)}\KeywordTok{.}
\end{Highlighting}
\end{Shaded}

This fragment is somewhat similar to the Java and Haskell fragments
above. It can be used to generate a string with the integers from
\texttt{X} to \texttt{Y} where each integer would be printed on a
separate line. (As with the Haskell fragment, it does not print the
string.)

This program fragment defines a \emph{database} consisting of four
\emph{clauses}.

The clause

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{X}\KeywordTok{,}\NormalTok{[}\DataTypeTok{X}\NormalTok{])}\KeywordTok{.}
\end{Highlighting}
\end{Shaded}

defines a \emph{fact}. For any \emph{variable} value \texttt{X} and list
\texttt{{[}X{]}} consisting of the single value \texttt{X},
\texttt{count(X,X,{[}X{]})} is asserted to be true.

The other three clauses are \emph{rules}. The left-hand-side of
\texttt{:-} is true if the right-hand-side is also true. For example,

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\NormalTok{[]) }\KeywordTok{:-} \DataTypeTok{X} \DataTypeTok{>} \DataTypeTok{Y}\KeywordTok{.}
\end{Highlighting}
\end{Shaded}

asserts that

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DataTypeTok{Y}\KeywordTok{,}\NormalTok{[])}
\end{Highlighting}
\end{Shaded}

is true when \texttt{X\ \textgreater{}\ Y}. The empty brackets denote an
empty list of values.

As a logic or relational language, we can \emph{query} the database for
any missing components. For example,

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    count(}\DecValTok{1}\KeywordTok{,}\DecValTok{1}\KeywordTok{,}\DataTypeTok{Z}\NormalTok{)}\KeywordTok{.}
\end{Highlighting}
\end{Shaded}

yields the value \texttt{Z\ =\ {[}1{]}}. However,

\begin{Shaded}
\begin{Highlighting}[]
\NormalTok{    count(}\DataTypeTok{X}\KeywordTok{,}\DecValTok{1}\KeywordTok{,}\NormalTok{[}\DecValTok{1}\NormalTok{])}\KeywordTok{.}
\end{Highlighting}
\end{Shaded}

yields the value \texttt{X\ =\ 1}. If more than one answer is possible,
the program can generate all of them in some nondeterministic order.

So, in some sense, where imperative and functional languages only run a
computation in one direction and give a single answer, Prolog can
potentially run a computation in multiple directions and give multiple
answers.

Example relational languages include Prolog, Parlog, and miniKanren.

Most Prolog implementations have imperative features such as the cut and
the ability to assert and retract clauses.

\hypertarget{other-programming-paradigms}{%
\subsection{Other Programming
Paradigms}\label{other-programming-paradigms}}

The imperative-declarative taxonomy described above divides programming
styles and language features on how they handle state and how they are
executed.

The computing community often speaks of other paradigms -- procedural,
modular, object-oriented, concurrent, parallel, language-oriented,
scripting, reactive, and so forth. The definitions of these
``paradigms'' may be quite fuzzy and vary significantly from one writer
to another. Sometimes a term is chosen for ``marketing'' reasons -- to
associate a language with some trend even though the language may be
quite different from others in that paradigm -- or to make a language
seem different and new even though it may not be significantly
different.

These paradigms tend to divide up programming styles and language
features along different dimensions than the primary taxonomy above.
Often the languages we are speaking of are subsets of the imperative
paradigm.

\hypertarget{procedural}{%
\subsubsection{Procedural}\label{procedural}}

TODO: Expand

\emph{Procedural} languages, for example, are imperative languages built
around the concept of subprograms -- procedures and functions.
Programmers divide a program's behavior into these program units that
call each other. Subprograms may be nested inside of other subprograms
to control the range of the program where the name of the subprogram is
known.

Languages like C, Fortran, Pascal, Lua, and Python are primarily
procedural languages, although most have evolved to support other
styles.

\hypertarget{modular}{%
\subsubsection{Modular}\label{modular}}

TODO: Expand

\emph{Modular programming} refers more to a design method for programs
and program libraries than to languages.

It means to decompose a program into packages of functionality that can
be developed separately. Key design and implementation details are
hidden inside the module -- the principle of \emph{information hiding}.
The interactions among modules is kept at a minimum -- exhibit a low
degree of coupling.

A language that provides constructs for defining modules, packages,
namespaces, or separate compilation units can assist in writing modular
programs.

\hypertarget{object-oriented}{%
\subsubsection{Object oriented}\label{object-oriented}}

The dominant paradigm since the early 1990s has been the
\emph{object-oriented paradigm}. Because this paradigm is likely
familiar with most readers, let's examine it in more detail.

We discuss object orientation in terms of an object model. Our
\emph{object model} includes four basic components:

\begin{enumerate}
\def\labelenumi{\arabic{enumi}.}
\tightlist
\item
  objects (i.e., abstract data structures)
\item
  classes (i.e., abstract data types)
\item
  inheritance (hierarchical relationships among abstract data types)
\item
  subtype polymorphism
\end{enumerate}

Note: Some writers consider \emph{dynamic binding} a basic component of
object orientation. Here we consider it an implementation technique for
subtype polymorphism.

\hypertarget{objects}{%
\paragraph{Objects}\label{objects}}

An \emph{object} is a characterized by three \emph{essential}
characteristics:

\begin{enumerate}
\def\labelenumi{\alph{enumi}.}
\tightlist
\item
  state
\item
  operations
\item
  identity
\end{enumerate}

An object is a separately identifiable entity that has a set of
operations and a state that records the effects of the operations. An
object is typically a \emph{first class} entity that can be stored in
variables and passed to or returned from subprograms.

The \emph{state} is the collection of information held (i.e., stored) by
the object.

\begin{itemize}
\tightlist
\item
  It can change over time.
\item
  It can change as the result of an operation performed on the object.
\item
  It cannot change spontaneously.
\end{itemize}

The various components of the state are sometimes called the
\emph{attributes} of the object.

An \emph{operation} is a procedure that takes the state of the object
and zero or more arguments and changes the state and/or returns one or
more values. Objects permit certain operations and not others.

If an object is \emph{mutable}, then an operation may change the stored
state so that a subsequent operation on that object acts upon the
modified state; the language is thus imperative.

If an object is \emph{immutable}, then an operation cannot change the
stored state; instead it returns a new object with the modified state.

\emph{Identity} means we can distinguish between two distinct objects
(even if they have the same state and operations).

As an example, consider an object for a student desk in a simulation of
a classroom. Student desks are distinct from each other. The relevant
\emph{state} might be attributes like location, orientation, person
using, items in the basket, items on top, etc. The relevant
\emph{operations} might be state-changing operations (called
\emph{mutator}, setter, or command operations) such as ``move the
desk'', ``seat student'', or ``remove from basket'' or might be
state-observing operations (called \emph{accessor}, getter, observer, or
query operations) such as ``is occupied'' or ``report items on
desktop''.

A language is \emph{object-based} if it supports objects as a language
feature.

Object-based languages include Ada, Modula, Clu, C++, Java, Scala, C\#,
and Smalltalk. Pascal (without module extensions), Algol, Fortran. and C
are not inherently object-based.

Some writers require that an object have additional characteristics, but
these notes consider these as important but \emph{non-essential}
characteristics of objects:

\begin{enumerate}
\def\labelenumi{\alph{enumi}.}
\setcounter{enumi}{3}
\tightlist
\item
  encapsulation
\item
  independent lifecycle
\end{enumerate}

The state may be \emph{encapsulated} within the object -- that is, not
be directly visible or accessible from outside the object.

The object may also have an \emph{independent lifecycle} -- that is, the
object may exist independently from the program unit that created it.

We do not include these as essential characteristics because they do not
seem required by the object metaphor. There are languages that use a
modularization feature to enforce encapsulation separately from the
object (or class) feature. Also, there are languages that may have local
``objects'' within a function or procedure.

TODO: Give examples of languages without d or e -- e.g., Lua, Oberon,
C++.

\hypertarget{classes}{%
\paragraph{Classes}\label{classes}}

A \emph{class} is a template or factory for creating objects.

\begin{itemize}
\item
  A class describes a collection of related objects (i.e.,
  \emph{instances} of the class).
\item
  Objects of the same class have common operations and a common set of
  possible states.
\item
  The concept of class is closely related to the concept of \emph{type}.
\end{itemize}

A class description includes definitions of:

\begin{itemize}
\tightlist
\item
  operations on objects of the class
\item
  the possible set of states
\end{itemize}

As an example, again consider a simulation of a classroom. There might
be a class \texttt{StudentDesk} from which specific instances can be
created as needed.

An object-based language is \emph{class-based} if the concept of class
occurs as a language feature and every object has a class.

Class-based languages include Clu, C++, Java, Scala, C\#, Smalltalk,
Ruby, and Ada 95. Ada 83 and Modula are not class-based.

At their core, JavaScript and Lua are object-based but not class-based.

In statically typed, class-based languages such as Java, Scala, C++, and
C\# classes are treated as types. Instances of the same class have the
same type.

However, some dynamically typed languages may have a more general
concept of type: If two objects have the same set of operations, then
they have the same type regardless of how the object was created.
Languages such as Smalltalk and Ruby have this characteristic --
sometimes informally called \emph{duck typing}. (If it walks like a duck
and quacks like a duck, then it is a duck.)

\hypertarget{inheritance}{%
\paragraph{Inheritance}\label{inheritance}}

A class C \emph{inherits} from class P if C's objects form a subset of
P's objects.

\begin{itemize}
\item
  Class C's objects must support all of the class P's operations (but
  perhaps are carried out in a special way).
\item
  Class C may support additional operations and an extended state (i.e.,
  more information fields).
\item
  Class C is called a \emph{subclass} or a \emph{child} or \emph{derived
  class}.
\item
  Class P is called a \emph{superclass} or a \emph{parent} or
  \emph{base} class.
\item
  Class P is sometimes called a \emph{generalization} of class C; class
  C is a \emph{specialization} of class P.
\end{itemize}

The importance of inheritance is that it encourages sharing and reuse of
both design information and program code. The shared state and
operations can be described and implemented in base classes and shared
among the subclasses.

As an example, again consider the student desks in a simulation of a
classroom. The \texttt{StudentDesk} class might be derived (i.e.,
inherit) from a class \texttt{Desk}, which in turn might be derived from
a class \texttt{Furniture}. In diagrams, it is the convention to draw
arrows (e.g., \(\longleftarrow\)) from the subclass to the superclass.

\begin{quote}
\texttt{Furniture} \(\longleftarrow\) \texttt{Desk} \(\longleftarrow\)
\texttt{StudentDesk}
\end{quote}

The simulation might also include a \texttt{ComputerDesk} class that
also derives from \texttt{Desk}.

\begin{quote}
\texttt{Furniture} \(\longleftarrow\) \texttt{Desk} \(\longleftarrow\)
\texttt{ComputerDesk}
\end{quote}

In Java and Scala, we can express the above inheritance relationships
using the \texttt{extends} keyword as follows.

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{class}\NormalTok{ Furniture  }\CommentTok{// extends cosmic root class for references}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}      }\CommentTok{// (java.lang.Object, scala.AnyRef)}

    \KeywordTok{class}\NormalTok{ Desk }\KeywordTok{extends}\NormalTok{ Furniture}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{class}\NormalTok{ StudentDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{class}\NormalTok{ ComputerDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}
\end{Highlighting}
\end{Shaded}

Both \texttt{StudentDesk} and \texttt{ComputerDesk} objects will need
operations to simulate a \texttt{move} of the entity in physical space.
The \texttt{move} operation can thus be implemented in the \texttt{Desk}
class and shared by objects of both classes. Invocation of operations to
\texttt{move} either a \texttt{StudentDesk} or a \texttt{ComputerDesk}
will be bound to the general \texttt{move} in the \texttt{Desk} class.

The \texttt{StudentDesk} class might inherit from a \texttt{Chair} class
as well as the \texttt{Desk} class.

\begin{quote}
\texttt{Furniture} \(\longleftarrow\) \texttt{Chair} \(\longleftarrow\)
\texttt{StudentDesk}
\end{quote}

Some languages support \emph{multiple inheritance} as shown above for
\texttt{StudentDesk} (e.g., C++, Eiffel). Other languages only support a
single inheritance hierarchy.

Because multiple inheritance is both difficult to use correctly and to
implement in a compiler, the designers of Java and Scala did not include
multiple inheritance of classes as features. Java has a single
inheritance hierarchy with a top-level class named \texttt{Object} from
which all other classes derive (directly or indirectly). Scala is
similar, with the corresponding top-level class named \texttt{AnyRef}.

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{class}\NormalTok{ StudentDesk }\KeywordTok{extends}\NormalTok{ Desk, Chair  }\CommentTok{// NOT VALID in Java}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}
\end{Highlighting}
\end{Shaded}

To see some of the problems in implementing multiple inheritance,
consider the above example. Class \texttt{StudentDesk} inherits from
class \texttt{Furniture} through two different paths. Do the data fields
of the class \texttt{Furniture} occur once or twice? What happens if the
intermediate classes \texttt{Desk} and \texttt{Chair} have conflicting
definitions for a data field or operation with the same name?

The difficulties with multiple inheritance are greatly decreased if we
restrict ourselves to inheritance of class \emph{interfaces} (i.e., the
signatures of a set of operations) rather than a supporting the
inheritance of the class \emph{implementations} (i.e., the instance data
fields and operation implementations). Since interface inheritance can
be very useful in design and programming, the Java designers introduced
a separate mechanism for that type of inheritance.

The Java \texttt{interface} construct can be used to define an interface
for classes separately from the classes themselves. A Java
\texttt{interface} may inherit from (i.e., \texttt{extend}) zero or more
other \texttt{interface} definitions.

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{interface}\NormalTok{ Location3D}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{interface}\NormalTok{ HumanHolder}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{interface}\NormalTok{ Seat }\KeywordTok{extends}\NormalTok{ Location3D, HumanHolder}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}
\end{Highlighting}
\end{Shaded}

A Java \texttt{class} may inherit from (i.e., \texttt{implement}) zero
or more interfaces as well as inherit from (i.e., \texttt{extend})
exactly one other \texttt{class}.

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{interface}\NormalTok{ BookHolder}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{interface}\NormalTok{ BookBasket }\KeywordTok{extends}\NormalTok{ Location3D, BookHolder}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}

    \KeywordTok{class}\NormalTok{ StudentDesk }\KeywordTok{extends}\NormalTok{ Desk }\KeywordTok{implements}\NormalTok{ Seat, BookBasket}
\NormalTok{    \{   }\KeywordTok{...   }\NormalTok{\}}
\end{Highlighting}
\end{Shaded}

This definition requires the \texttt{StudentDesk} class to provide
actual implementations for all the operations from the
\texttt{Location3D}, \texttt{HumanHolder}, \texttt{BookHolder},
\texttt{Seat}, and \texttt{BookBasket} interfaces. The
\texttt{Location3D} operations will, of course, need to be implemented
in such a way that they make sense as part of both the
\texttt{HumanHolder} and \texttt{BookHolder} abstractions.

The Scala \texttt{trait} provides a more powerful, and more complex,
mechanism than Java's original \texttt{interface}. In addition to
signatures, a \texttt{trait} can define method implementations and data
fields. These traits can be added to a class in a controlled, linearized
manner to avoid the semantic and implementation problems associated with
multiple inheritance of classes. This is called \emph{mixin}
inheritance.

Java 8 generalized interfaces to allow default implementations of
methods.

Most statically typed languages treat subclasses as \emph{subtypes}.
That is, if \texttt{C} is a subclass of \texttt{P}, then the objects of
type \texttt{C} are also of type \texttt{P}. We can \emph{substitute} a
\texttt{C} object for a \texttt{P} object in all cases.

However, the inheritance mechanism in languages in most class-based
languages (e.g., Java) does not automatically preserve substitutability.
For example, a subclass can change an operation in the subclass to do
something totally different from the corresponding operation in the
parent class.

\hypertarget{polymorphism}{%
\paragraph{Polymorphism}\label{polymorphism}}

The concept of \emph{polymorphism} (literally ``many forms'') means the
ability to hide different implementations behind a common interface.
Polymorphism appears in several forms in programming languages. We will
discuss these more later.

\emph{Subtype polymorphism} (sometimes called \emph{polymorphism by
inheritance}, \emph{inclusion polymorphism}, or \emph{subtyping}) means
the association of an operation invocation (i.e., procedure or function
call) with the appropriate operation implementation in an inheritance
(subtype) hierarchy.

This form of polymorphism is usually carried out at run time. That
implementation is called \emph{dynamic binding}. Given an object (i.e.,
class instance) to which an operation is applied, the system will first
search for an implementation of the operation associated with the
object's class. If no implementation is found in that class, the system
will check the superclass, and so forth up the hierarchy until an
appropriate implementation is found. Implementations of the operation
may appear at several levels of the hierarchy.

The combination of dynamic binding with a well-chosen inheritance
hierarchy allows the possibility of an instance of one subclass being
substituted for an instance of a different subclass during execution. Of
course, this can only be done when none of the extended operations of
the subclass are being used.

As an example, again consider the simulation of a classroom. As in our
discussion of inheritance, suppose that the \texttt{StudentDesk} and
\texttt{ComputerDesk} classes are derived from the \texttt{Desk} class
and that a general \texttt{move} operation is implemented as a part of
the \texttt{Desk} class. This could be expressed in Java as follows:

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{class}\NormalTok{ Desk }\KeywordTok{extends}\NormalTok{ Furniture}
\NormalTok{    \{   ...}
        \KeywordTok{public} \DataTypeTok{void} \FunctionTok{move}\NormalTok{(...)}
\NormalTok{        ...}
\NormalTok{    \}}

    \KeywordTok{class}\NormalTok{ StudentDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   ...}
        \CommentTok{// no move(...) operation here}
\NormalTok{        ...}
\NormalTok{    \}}

    \KeywordTok{class}\NormalTok{ ComputerDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   ...}
        \CommentTok{// no move(...) operation here}
\NormalTok{        ...}
\NormalTok{    \}}
\end{Highlighting}
\end{Shaded}

As we noted before, invocation of operations to \texttt{move} either a
\texttt{StudentDesk} or a \texttt{ComputerDesk} instance will be bound
to the general \texttt{move} in the \texttt{Desk} class.

Extending the example, suppose that we need a special version of the
\texttt{move} operation for \texttt{ComputerDesk} objects. For instance,
we need to make sure that the computer is shut down and the power is
disconnected before the entity is moved.

To do this, we can define this special version of the \texttt{move}
operation and associate it with the \texttt{ComputerDesk} class. Now a
call to \texttt{move} a \texttt{ComputerDesk} object will be bound to
the special \texttt{move} operation, but a call to \texttt{move} a
\texttt{StudentDesk} object will still be bound to the general
\texttt{move} operation in the \texttt{Desk} class.

The definition of \texttt{move} in the \texttt{ComputerDesk} class is
said to \emph{override} the definition in the \texttt{Desk} class.

In Java, this can be expressed as follows:

\begin{Shaded}
\begin{Highlighting}[]
    \KeywordTok{class}\NormalTok{ Desk }\KeywordTok{extends}\NormalTok{ Furniture }
\NormalTok{    \{   ...}
        \KeywordTok{public} \DataTypeTok{void} \FunctionTok{move}\NormalTok{(...)}
\NormalTok{        ...}
\NormalTok{    \}}

    \KeywordTok{class}\NormalTok{ StudentDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   ...}
        \CommentTok{// no move(...) operation here}
\NormalTok{        ...}
\NormalTok{    \}}

    \KeywordTok{class}\NormalTok{ ComputerDesk }\KeywordTok{extends}\NormalTok{ Desk}
\NormalTok{    \{   ...}
        \KeywordTok{public} \DataTypeTok{void} \FunctionTok{move}\NormalTok{(...)}
\NormalTok{        ...}
\NormalTok{    \}}
\end{Highlighting}
\end{Shaded}

A class-based language is \emph{object-oriented} if class hierarchies
can be incrementally defined by an inheritance mechanism and the
language supports polymorphism by inheritance along these class
hierarchies.

Object-oriented languages include C++, Java, Scala, C\#, Smalltalk, and
Ada 95. The language Clu is class-based, but it does not include an
inheritance facility.

Other object-oriented languages include Objective C, Object Pascal,
Eiffel, and Oberon 2.

\hypertarget{prototype-based}{%
\subsubsection{Prototype based}\label{prototype-based}}

TODO: Give example

Classes and inheritance are not the only way to support relationships
among objects in object-based languages. Another approach of growing
importance is the use of \emph{prototypes}.

A \emph{prototype-based} language does not have the concept of class as
defined above. It just has objects. Instead of using a class to
instantiate a new object, a program copies (or clones) an existing
object -- the \emph{prototype} -- and modifies the copy to have the
needed attributes and operations.

Each prototype consists of a collection of \emph{slots}. Each slot is
filled with either a data attribute or an operation

This cloning approach is more flexible than the class-based approach.

In a class-based language, we need to define a new class or subclass to
create a variation of an existing type. For example, we may have a
\texttt{Student} class. If we want to have students who play chess, then
we would need to create a new class, say \texttt{ChessPlayingStudent},
to add the needed data attributes and operations.

In a class-based language, the boundaries among categories of objects
specified by classes should be \emph{crisply defined}. That is, an
object is in a particular class or it is not. Sometimes this crispness
may be unnatural.

In a prototype-based language, we simply clone a student object and add
new slots for the added data and operations. This new object can be a
prototype for further objects.

In a prototype-based language, the boundaries between categories of
objects created by cloning may be fuzzy. One category of objects may
tend to blend into others. Sometimes this fuzziness may be more natural.

Consider categories of people associated with a university. These
categories may include \texttt{Faculty}, \texttt{Staff},
\texttt{Student}, and \texttt{Alumnus}. Consider a \emph{student} who
gets a BSCS degree, then accepts a \emph{staff} position as a programmer
and stays a student by starting an MS program part-time, and then later
teaches a course as a graduate student. The same person who started as a
student thus evolves into someone who is in several categories later.
And he or she may also be a chess player.

Instead of static, class-based inheritance and polymorphism, some
languages exhibit prototype-based \emph{delegation}. If the appropriate
operation cannot be found on the current object, the operation can be
delegated to its prototype, or perhaps to some other related, object.
This allows dynamic relationships along several dimensions. It also
means that the ``copying'' or ``cloning'' may be partly logical rather
than physical.

Prototypes and delegation are more basic mechanisms than inheritance and
polymorphism. The latter can often be implemented (or perhaps
``simulated'') using the former.

Self, JavaScript, and Lua are prototype-based languages.

\hypertarget{motivating-functional-programming-john-backus}{%
\subsection{Motivating Functional Programming: John
Backus}\label{motivating-functional-programming-john-backus}}

John W. Backus (December 3, 1924 -- March 17, 2007) was a pioneer in
research and development of programming languages. He was the primary
developer of Fortran while a developer at IBM in the mid-1950s. Fortran
is the first widely used high-level language. Backus was also a
participant in the international team that designed the influential
languages Algol 58 and Algol 60 a few years later. The notation used to
describe the Algol 58 language syntax--Backus-Naur Form (BNF)--bears his
name. This notation continues to be used to this day.

In 1977, ACM bestowed its Turing Award on Backus in recognition of his
career of accomplishments. (This award is sometimes described as the
``Nobel Prize for computer science''.) The annual recipient of the award
gives an address to a major computer science conference. Backus's
address was titled ``Can Programming Be Liberated from the von Neumann
Style? A Functional Style and Its Algebra of Programs''.

Although functional languages like Lisp go back to the late 1950's,
Backus's address did much to stimulate research community's interest in
functional programming languages and functional programming over the
past 40 years.

The next subsection gives excerpts from Backus' Turing Award address
published as the article ``Can Programming Be Liberated from the von
Neumann Style? A Functional Style and Its Algebra of Programs''
{[}Backus 1978{]}.

\hypertarget{excerpts-from-backuss-turing-award-address}{%
\subsubsection{Excerpts from Backus's Turing Award
Address}\label{excerpts-from-backuss-turing-award-address}}

Programming languages appear to be in trouble. Each successive language
incorporates, with little cleaning up, all the features of its
predecessors plus a few more. Some languages have manuals exceeding 500
pages; others cram a complex description into shorter manuals by using
dense formalisms. \ldots{} Each new language claims new and fashionable
features, such as strong typing or structured control statements, but
the plain fact is that few languages make programming sufficiently
cheaper or more reliable to justify the cost of producing and learning
to use them.

Since large increases in size bring only small increases in power,
smaller, more elegant languages such as Pascal continue to be popular.
But there is a desperate need for a powerful methodology to help us
think about programs, and no conventional language even begins to meet
that need. In fact, conventional languages create unnecessary confusion
in the way we think about programs. \ldots{} In order to understand the
problems of conventional programming languages, we must first examine
their intellectual parent, the von Neumann computer. What is a von
Neumann computer? When von Neumann and others conceived of it \ldots{}
{[}in the 1940's{]}, it was an elegant, practical, and unifying idea
that simplified a number of engineering and programming problems that
existed then. Although the conditions that produced its architecture
have changed radically, we nevertheless still identify the notion of
``computer'' with this \ldots{} concept.

In its simplest form a von Neumann computer has three parts: a central
processing unit (or CPU), a store, and a connecting tube that can
transmit a single word between the CPU and the store (and send an
address to the store). I propose to call this tube the \emph{von Neumann
bottleneck}. The task of a program is to change the contents of the
store in some major way; when one considers that this task must be
accomplished entirely by pumping single words back and forth through the
von Neumann bottleneck, the reason for its name becomes clear.

Ironically, a large part of the traffic in the bottleneck is not useful
data but merely names of data, as well as operations and data used only
to compute such names. Before a word can be sent through the tube its
address must be in the CPU; hence it must either be sent through the
tube from the store or be generated by some CPU operation. If the
address is sent form the store, then its address must either have been
sent from the store or generated in the CPU, and so on. If, on the other
hand, the address is generated in the CPU, it must either be generated
by a fixed rule (e.g., ``add 1 to the program counter'') or by an
instruction that was sent through the tube, in which case its address
must have been sent, and so on.

Surely there must be a less primitive way of making big changes in the
store than by pushing vast numbers of words back and forth through the
von Neumann bottleneck. Not only is this tube a literal bottleneck for
the data traffic of a problem, but, more importantly, it is an
intellectual bottleneck that has kept us tied to word-at-a-time thinking
instead of encouraging us to think in terms of the larger conceptual
units of the task at hand. \ldots{}

Conventional programming languages are basically high level, complex
versions of the von Neumann computer. Our \ldots{} old belief that there
is only one kind of computer is the basis our our belief that there is
only one kind of programming language, the conventional--von
Neumann--language. The differences between Fortran and Algol 68,
although considerable, are less significant than the fact that both are
based on the programming style of the von Neumann computer. Although I
refer to conventional languages as ``von Neumann languages'' to take
note of their origin and style, I do not, of course, blame the great
mathematician for their complexity. In fact, some might say that I bear
some responsibility for that problem.

Von Neumann programming languages use variables to imitate the
computer's storage cells; control statements elaborate its jump and test
instructions; and assignment statements imitate its fetching, storing,
and arithmetic. The assignment statement is the von Neumann bottleneck
of programming languages and keeps us thinking in word-at-at-time terms
in much the same way the computer's bottleneck does.

Consider a typical program; at its center are a number of assignment
statements containing some subscripted variables. Each assignment
statement produces a one-word result. The program must cause these
statements to be executed many times, while altering subscript values,
in order to make the desired overall change in the store, since it must
be done one word at a time. The programmer is thus concerned with the
flow of words through the assignment bottleneck as he designs the nest
of control statements to cause the necessary repetitions.

Moreover, the assignment statement splits programming into two worlds.
The first world comprises the right sides of assignment statements. This
is an orderly world of expressions, a world that has useful algebraic
properties (except that those properties are often destroyed by side
effects). It is the world in which most useful computation takes place.

The second world of conventional programming languages is the world of
statements. The primary statement in that world is the assignment
statement itself. All the other statements in the language exist in
order to make it possible to perform a computation that must be based on
this primitive construct: the assignment statement.

This world of statements is a disorderly one, with few useful
mathematical properties. Structured programming can be seen as a modest
effort to introduce some order into this chaotic world, but it
accomplishes little in attacking the fundamental problems created by the
word-at-a-time von Neumann style of programming, with its primitive use
of loops, subscripts, and branching flow of control.

Our fixation on von Neumann languages has continued the primacy of the
von Neumann computer, and our dependency on \emph{it} has made non-von
Neumann languages uneconomical and has limited their development. The
absence of full scale, effective programming styles founded on non-von
Neumann principles has deprived designers of an intellectual foundation
for new computer architectures. \ldots{}

\hypertarget{aside-on-the-disorderly-world-of-statements}{%
\subsubsection{Aside on the disorderly world of
statements}\label{aside-on-the-disorderly-world-of-statements}}

Backus states that ``the world of statements is a disorderly one, with
few mathematical properties''. Even in 1977 this was a bit overstated
since work by Hoare on
\href{localcopy/Hoare_Axiomatic_Basis.pdf}{\emph{axiomatic semantics}},
by Dijkstra on
\href{localcooy/Dijskstra_Guarded_Commands.pdf}{\emph{weakest
precondition (wp) calculus}}, and by others had already appeared.

However, because of the referential transparency property of purely
functional languages, reasoning can often be done in an equational
manner within the context of the language itself. We examine this
convenient approach later in these notes.

In contrast, the \emph{wp}-calculus and other axiomatic semantic
approaches must project the problem from the world of programming
language statements into the world of predicate calculus, which is much
more orderly. We leave this study to other courses (such as CSci 550,
Program Semantics and Derivation).

\hypertarget{perspective-from-four-decades-later}{%
\subsubsection{Perspective from four decades
later}\label{perspective-from-four-decades-later}}

In his Turing Award Address, Backus went on to describe FP, his proposal
for a functional programming language. He argued that languages like FP
would allow programmers to break out of the von Neumann bottleneck and
find new ways of thinking about programming.

FP itself did not catch on, but the widespread attention given to
Backus' address and paper stimulated new interest in functional
programming to develop by researchers around the world. Modern languages
like Haskell developed partly from the interest generated.

In the 21st Century, the software industry has become more interested in
functional programming. Some functional programming features now appear
in most mainstream programming languages (e.g., in Java 8). This
interest seems to driven primarily by two concerns:

\begin{itemize}
\tightlist
\item
  managing the complexity of large software systems effectively
\item
  exploiting multicore processors conveniently and safely
\end{itemize}

The functional programming paradigm is able to address these concerns
because of such properties such as referential transparency, immutable
data structures, and composability of components. We look at these
aspects later in these notes.

\hypertarget{conclusions}{%
\subsection{Conclusions}\label{conclusions}}

TODO: Add

\hypertarget{exercises}{%
\subsection{Exercises}\label{exercises}}

TODO: Add

\hypertarget{acknowledgements}{%
\subsection{Acknowledgements}\label{acknowledgements}}

I adapted and revised much of this work in Summer and Fall 2016 from my
previous materials.

\begin{itemize}
\item
  Primary Programming Paradigms from chapter 1 of my \emph{Notes on
  Functional Programming with Haskell}, which I wrote originally in the
  mid-1990s for the Gofer dialect of Haskell but later updated to the
  1998 and 2010 Haskell standards. I updated this content to expand the
  discussion of the paradigms to include examples.
\item
  Object-Oriented programming paradigm from my notes \emph{Introduction
  to Object Orientation}, which I wrote originally for the first UM C++
  (CSci 490) and Java-based (CSci 211) classes in 1996 but expanded and
  adapted for other courses.
\item
  Motivating Functional Programming from chapter 1 of my \emph{Notes on
  Functional Programming with Haskell}.
\end{itemize}

In 2017, I continued to develop this material as a part of Chapter 1 of
my Haskell-based programming languages ``textbook''. I added new
material on other paradigms, particularly on the Prototype-based
paradigm (first drafted in Fall 2016).

In Spring 2018, I pulled this Programming Paradigms document back out of
the Fundamentals chapter to continue development. I wanted a less
cluttered discussion of paradigms, particularly the object-oriented
paradigm.

I maintain these notes as text in Pandoc's dialect of Markdown using
embedded LaTeX markup for the mathematical formulas and then translate
the notes to HTML, PDF, and other forms as needed.

\hypertarget{references}{%
\subsection{References}\label{references}}

TODO: Complete and update

\begin{description}
\tightlist
\item[{[}Backus 1978{]}]
John Backus. \href{Backus_Turing_Award_Address.pdf}{Can Programming Be
Liberated from the von Neumann Style? A Functional Style and Its Algebra
of Programs}, \emph{Communications of the ACM}, Vol. 21, No.~8, pages
613--41, August 1978 (ACM Turing Award Lecture, 1977).
\item[{[}Bird 1988{]}]
Richard S. Bird and Phillip L. Wadler. \emph{Functional Programming},
Prentice Hall, 1988.
\item[{[}Budd 1995{]}]
Timothy A. Budd. \emph{Multiparadigm Programming in Leda},
Addison-Wesley, 1995.
\item[{[}Budd 2000{]}]
Timothy Budd. \emph{Understanding Object-Oriented Programming with
Java}, Updated Edition, Addison Wesley, 2000.
\item[{[}Craig 2007{]}]
Iain D. Craig. \emph{Object-Oriented Programming Languages}, Springer
2007. (Especially chapter 1 ``Introduction'' and chapter 3 ``Prototype
and Actor Languages'')
\item[{[}Cunningham 2014{]}]
H. Conrad Cunningham.
\href{https://john.cs.olemiss.edu/~hcc/csci450/notes/haskell_notes.pdf}{\emph{Notes
on Functional Programming with Haskell}}, 1994-2014.
\item[{[}Horstmann 1995{]}]
Cay S. Horstmann. \emph{Mastering Object-Oriented Design in C++}, Wiley,
1995. (Especially chapters 3-6 on ``Implementing Classes'',
``Interfaces'', ``Object-Oriented Design'', and ``Invariants'' which
influenced my views on object-oriented design and programming)
\item[{[}Hudak 1989{]}]
Paul Hudak. Conception, Evolution, and Application of Functional
Programming Languages, \emph{ACM Computing Surveys}, Vol. 21,
No.~pp.~359-411, 1989. (Especially the ``Introduction''w section.)
\end{description}

\hypertarget{terms-and-concepts}{%
\subsection{Terms and Concepts}\label{terms-and-concepts}}

TODO: Complete and update

Programming language paradigms (imperative, declarative, functional,
relational or logic language), program state, implicit versus explicit
state, execution of commands versus evaluation of expressions,
abstraction, procedural abstraction, data abstraction, procedure,
function, method

\end{document}
