#+Title: 3a – Two Language Kernels (Expressions and Memory Models)
#+Subtitle: ~while~ and ~sa-decl~
#+Author: Mark Armstrong, PhD Candidate, McMaster University
#+Date: Fall, 2019
#+Description: Two kernel languages; one imperative and one declarative.
#+Options: toc:nil
#+Reveal_root: http://cdn.jsdelivr.net/reveal.js/3.0.0/
#+Reveal_init_options: width:1600, height:900, controlsLayout:'edges',
#+Reveal_init_options: margin: 0.1, minScale:0.125, maxScale:5
#+Reveal_extra_css: local.css
#+html: <script src="https://cdnjs.cloudflare.com/ajax/libs/headjs/0.96/head.min.js"></script>

* LaTeX Header                                  :ignore:

#+LaTeX_header: \usepackage{amsthm}
#+LaTeX_header: \theoremstyle{definition}
#+LaTeX_header: \newtheorem{definition}{Definition}[section]

#+LaTeX_header: \newenvironment{NOTES}{
#+LaTeX_header:   \begin{center}
#+LaTeX_header:   \begin{tabular}
#+LaTeX_header:   {|p{0.9\textwidth}|}
#+LaTeX_header:   \hline\\
#+LaTeX_header:   \begin{scriptsize}
#+LaTeX_header: }{
#+LaTeX_header:   \end{scriptsize}
#+LaTeX_header:   \\\\\hline
#+LaTeX_header:   \end{tabular}
#+LaTeX_header:   \end{center}
#+LaTeX_header: }

* Preamble

** Notable references
:PROPERTIES:
:CUSTOM_ID: Notable-references
:END:



- Concepts, Techniques, and Models of Computer Programming, Van Roy
  & Haridi
  - Chapter 2 – Declarative Computation Model
    - Section 2.2 – The single-assignment store
- Principles of Programming Languages, Dowek
  - Chapter 1 – Imperative Core
    - Section 1.3.1 – The Concept of a State
    - Section 1.3.2 – Decomposition of the State
    - Section 1.3.3 – A Visual Representation of a State

** Update history

- Sept. 25 ::
  - Original version (part a) posted

** TODO Table of contents

# The table of contents are added using org-reveal-manual-toc,
# and so must be updated upon changes or added last.

#+HTML: <font size="-1">
#+begin_scriptsize
...
#+end_scriptsize
#+HTML: </font>

* Language kernels

#+begin_quote
In this approach, a practical language is translated into
a /kernel language/ that consists of a small number
of /programmer-significant/ elements. The rich set of abstractions
and syntax is encoded into the small kernel language.
This gives both programmer and student
a clear insight into what the language does.

— Concepts, Techniques, and Models of Computer Programming
#+end_quote

** A meta-note about exams

Some of these kernel languages will be proper subsets of
the languages we use in the course (especially Oz),
but some will be theoretical languages.

In midterms and exams, you will generally /not/ be expected
to have memorised the syntax of such theoretical languages.

In fact (unless it is announced otherwise before the tests),
in questions regarding these languages we will
provide you (the relevant portions of) the CFG defining the
language syntax.

** Justifying the kernel

For a kernel language to be “useful”, we must
convince ourselves that it includes
- enough abstractions to be practical, but
- not so many that it becomes difficult to reason about.

Almost any general purpose language serves as an example
that violates the second condition.

An example of a language which violates the first
is the “/Goto/” language. In this language,
- the only type is ℕ (the natural numbers),
- the only control structure is a conditional /jump/, and
- the only way to modify variables is to increment
  or decrement them by 1.
#+begin_src text
⟨stmt⟩ ∷= [label] ⟨command⟩
       | ⟨stmt⟩ ; ⟨stmt⟩

⟨command⟩ ∷= skip
          | var ++
          | var --
          | if-zero var goto label
#+end_src
This language is useful for studying computability,
but not so much for studying language design.

** Extending the kernel

There are two ways we will extend our kernel languages:
- syntactic sugar, and
- linguistic abstractions.

Syntactic sugar
- is a shortcut notation that can be translated into the
  kernel language.
- For example, omitting keywords or rearranging expressions.
  - Such as the prefix control structures in Ruby.

Whereas a linguistic abstraction
- is a new abstraction which can be translated into the
  kernel language.
  - Remember than an abstraction is a tool or device
    that solves a particular problem.
- For example, adding /functions/ to a language with only
  /procedures/, or ~for~ loops to a language with only ~while~ loops.

* A common set of expressions – /Expr₀/

For simplicity's sake, we will (for the moment)
restrict our attention to languages with
- only integer and boolean expressions,
- only integer and /reference/ variables,
and we will not assume any type checking.

The /abstract syntax/ of these expressions is given by the grammar
#+begin_src text
⟨expr⟩ ∷= ⟨bexpr⟩ | ⟨iexpr⟩
⟨bexpr⟩ ∷= true | false
        | ⟨expr⟩ == ⟨expr⟩ | ⟨expr⟩ \= ⟨expr⟩
        | ⟨expr⟩ =< ⟨expr⟩ | ⟨expr⟩ < ⟨expr⟩
        | ⟨expr⟩ >= ⟨expr⟩ | ⟨expr⟩ > ⟨expr⟩
⟨iexpr⟩ ∷= number | var
        | ⟨iexpr⟩ + ⟨iexpr⟩ | ⟨iexpr⟩ - ⟨iexpr⟩
        | ⟨iexpr⟩ * ⟨iexpr⟩ | ⟨iexpr⟩ div ⟨iexpr⟩ | ⟨iexpr⟩ mod ⟨iexpr⟩
#+end_src

** Why subscript zero?

We will later introduce more basic types than just
integer and boolean (as well as discussing type checking).

So we call this simple language of expressions
/Expr₀/.

* The memory models

We are going to define two kernel languages;
one imperative, and one declarative.

Before we get to the statements of the languages, we need to explain
the memory model underlying each.
- The languages are built specifically for their memory models.

We will call these two memory models:
- /Explicit state (with reference types)/.
  - The memory model that applies to most imperative languages.
  - So, likely what you are familiar with.
- /Single-assignment store/.
  - A memory model suitable for declarative languages.
  - Particularly useful for its simple support of concurrency.

We begin though by discussing a simpler model,
which we call /explicit state without reference types/.

** Assignment vs Binding, Identifier vs Variable

A /binding/
- is an association between a variable and some entity.
  - For instance, a value, or an address/memory reference.
- Generally, we use the term /binding/ to mean a /permanent binding/;
  once created, such a binding never changes.
- We instead use /assignment/ to refer to non-permanant bindings.

In the simplest memory models, values are simply assigned to variables;
memory is a mapping between variable names and values.

In general, things are more complex, and it is useful to distinguish the terms
- /identifier/ to refer to the names of variables as they appear in the
  program source, and
- /variable/ to refer to the abstract notion of a cell of memory.

** States, environments

We will generally denote the contents of memory using
the symbols ~σ~ (sigma) and ~τ~ (tau), possibly with
subscripts (~σ₁~, ~τ₂~, etc.) or primes (~σ′~, ~τ‴~, etc.).

We use notation similar to substitution to /update/
memory states.
- ~σ[x ≔ v]~ is read as ~σ~ with ~x~ updated to be ~v~.

We will also need to discuss an /environment/
for variables and procedures/functions;
we will use ~Σ~ (Sigma), adorned with subscripts or primes,
to denote environments.

** Explicit state without reference types

In the explicit state without reference types model,
we can view
- state as a mapping from identifiers to values.

So a state σ is a mapping between identifiers and values.
- ~σ : Identifier → Value~

This is a nice, simple mental model.
- But it is /too/ simple; most imperative languages include
  a /reference type/ abstraction that cannot be represented by
  this model.

*** Visualisation of explicit state without reference types

#+begin_quote
[[file:images/explicit-state-without-references.png]]
#+end_quote

If ~σ~ is this state, the update ~σ[x ≔ v]~ changes the
arrow coming from ~x~ to instead point to value ~v~.

**** The diagram                             :noexport:

#+begin_src ditaa :file images/explicit-state-without-references.png
+-------------+     +------------+
| Identifiers |     |   Values   |
| {d}         |     | {s}        |
|             |     |            |
|      …      |     |    …       |
|             |  σ  |            |
|      x ----=|=----|=-->5       |
|             |     |            |
|      y ----=|=----|=-->22      |
|             |     |            |
|      z ----=|=----|=-->true    |
|             |     |            |
|      …      |     |    …       |
|             |     |            |
+-------------+     +------------+
#+end_src

#+RESULTS:
[[file:images/explicit-state-without-references.png]]

** Explicit state with reference types

When we add the concept of /references/ or /addresses/ to our memory model,
we must update our notion of state; we now view
- state as a mapping from /references/ to values.
  - Rather than from /identifiers/ to values.
- We then need an /environment/ to map identifiers to references.

The addition of references to our model provides the abstractions
- /constants/, as identifiers mapped to directly to values,
- /reference type variables/, as identifiers mapped to a reference
  /which maps to a reference/.

*** Visualisation of explicit state with reference types

#+begin_quote
[[file:images/explicit-state-with-references.png]]
#+end_quote
In this memory configuration, ~x~ is a constant, ~y~ is a (simple) variable,
and ~z~ is a /reference/ variable.

Assignment changes the arrows leaving /references/; the arrows
leaving identifiers are fixed.

So if this state is ~σ~, ~σ[r₁ ≔ v]~ would be a new state where
~r₁~ points to ~v~ instead of ~5~.

**** The diagram                             :noexport:

#+begin_src ditaa :file images/explicit-state-with-references.png
+-------------+     +---------------------------------+
| Identifiers |     |            Values               |
| {d}         |     | {s}                             |
|             |     |                                 |
|      …      |     |                                 |
|             |  Σ  |                                 |
|      x -----|-----|--->5 <----------------------\   |
|             |     |            +-------------+  |   |
|      y -----|-----|-----\      | References  |  |   |
|             |     |     |      | {d}         |  |σ  |
|      z -----|-----|--\  |      |     …       |  |   |
|             |     |  |  \------|---> r₁ =----|=-/   |
|      …      |     |  |         |             |      |
|             |     |  |         |     ^       |      |
|             |     |  |         |     |       |      |
|             |     |  |         |     \-=-\   |      |
|             |     |  |         |         |σ  |      |
|             |     |  \---------|---> r₂ -/   |      |
|             |     |            |     …       |      |
|             |     |            +-------------+      |
+-------------+     +---------------------------------+
#+end_src

#+RESULTS:
[[file:images/explicit-state-with-references.png]]

** Single-assignment store

In a single-assignment store, variables can be bound to values
/at most once/.
- Once (totally) bound, a variable is /indistinguishable/
  from the value it is bound to.

We consider a single-assignment store model which allows /partial bindings/.
- A value can involve variables.
  - In which case we call it a /partial/ value.
  - If a value is /just/ a variable, we call the binding
    a /variable-variable/ binding.
- The variables in a value may be bound later.
  - A variable bound to a partial value is called /partially bound/.
  - As opposed to a /totally bound/ variable.

*** Visualisation of single assignment store

#+begin_quote
[[file:images/single-assignment-store.png]]
#+end_quote

In this memory configuration,
- variable ~x~ is (totally) bound to the value ~5~,
- variable ~y~ is (partially) bound to the value ~2 + z~,
- variable ~z~ and ~z′~ are bound together, but neither is bound to a value.

**** The diagram                             :noexport:

#+begin_src ditaa :file images/single-assignment-store.png
+-------------+         +----------------------------+
| Identifiers |         |       (Partial) Values     |
| {d}         |         | {s}                        |
|             |         | +-----------+              |
|      …      |         | | Variables |              |
|             |         | | {d}       |              |
|             |         | |           |              |
|             |         | |     …     |              |
|             |    Σ    | |           |  σ           |
|      X -----|---------|-|---> x =---|=---> 5       |
|             |         | |           |              |
|      Y -----|---------|-|---> y =---|=---> 2 + z   |
|             |         | |           |  σ       |   |
|      Z  ----|------\  | |     /=----|=---------/   |
|             |      |  | |     |     |              |
|      Z′ ----|-\    |  | |     v     |              |
|             | |    |  | |           |              |
|      …      | |    \--|-|---> z     |              |
|             | |       | |           |              |
|             | |       | |     ^     |              |
|             | |       | |     |     |              |
|             | |       | |     :σ    |              |
|             | |       | |     |     |              |
|             | |       | |     v     |              |
|             | |       | |           |              |
|             | \-------|-|---> z′    |              |
|             |         | |           |              |
|             |         | |     …     |              |
|             |         | |           |              |
|             |         | +-----------+              |
|             |         |                            |
+-------------+         +----------------------------+
#+end_src

#+RESULTS:
[[file:images/single-assignment-store.png]]

* The imperative “core” – ~While~ :noexport:

The basic operation in imperative languages is the /assignment/.
To make a Turing-complete language, we additionally need
/sequencing/ and some /control structures/.
- Sometimes ~;~ is used to sequence instructions;
  we will generally just use whitespace (particularly, newlines).
- For Turing completeness, a conditional statement and a
  potentially infinite loop statement are sufficient.
  - A conditional and a jump (goto) are simpler
    (and less restrictive), but jumps are hard to reason about.
  - We instead prefer a conditional and a ~while~ loop.

** A first language based on ~while~

So let us define a kernel for imperative languages
based on the ~while~ loop and an ~if-then-else~.
We'll call this language ~While₀~.
#+begin_src text
⟨stmt⟩ ∷=
  skip
| var = ⟨expr⟩
| ⟨stmt⟩ ⟨stmt⟩
| if ⟨bexpr⟩ then ⟨stmt⟩ else ⟨stmt⟩ end
| while ⟨bexpr⟩ do ⟨stmt⟩ end
#+end_src

** The full ~While~ language

#+begin_quote
Most [imperative] programming languages have, among others,
five constructs: assignment, variable declaration, sequence,
test and loop. These constructs form the /imperative core/ of
the language.

— Principles of Programming Languages (Dowek)
#+end_quote

We add the “do nothing” command ~skip~ to obtain our language
~while~.
#+begin_src text
⟨stmt⟩ ∷=
  skip
| int var
| var = ⟨expr⟩
| ⟨stmt⟩ ⟨stmt⟩
| if ⟨bexpr⟩ then ⟨stmt⟩ else ⟨stmt⟩ end
| while ⟨bexpr⟩ do ⟨stmt⟩ end
#+end_src

* A declarative model – ~SA-Decl~ :noexport:

#+begin_src text
⟨stmt⟩ ∷=
  skip                                           Empty statement
| ⟨stmt⟩ ⟨stmt⟩                                    Sequence
| local ⟨var⟩ in ⟨stmt⟩ end                        Variable creation
| ⟨var⟩ = ⟨var⟩                                    Binding
| ⟨var⟩ = ⟨value⟩                                  Value creation
| if ⟨var⟩ then ⟨stmt⟩ else ⟨stmt⟩ end              Conditional
| case ⟨var⟩ of ⟨pattern⟩ then ⟨s⟩ else ⟨s⟩ end      Pattern match
| `{` {⟨var⟩}⁺  `}`                                Procedure application
#+end_src