We Introduce The Hume Language

Published Date: 02 Nov 2017

In this chapter we introduce the Hume Language, HW-Hume dynamic operational semantics and relevant research on Hume.

Our HW-Hume Big Step operational semantics in Isabelle/HOL in Chapter~\ref{chap:HI} is based on HW-Hume dynamic operational semantics.

\section{Hume Language} \label{sect:Hume}

\subsection{Hume Language Introduction}

Hume (Higher-order Unified Meta-Environment)~\cite{Michaelson:Hume:Manual, Michaelson:Hume:Report} is an experimental strongly typed, functional and concurrent computer language, which is not yet widely used.

It has been designed to support a high level of expressive power for high reliability applications such as safety-critical or embedded systems, and provide strong guarantees of dynamic behavioural properties such as execution time and space usage.

It aims to extend the frontiers of language design for such systems, introducing new levels of abstraction and provability.

It is paramount that Hume programs have predictable and, preferably, provable properties.

The properties of determinism, termination and bounded time and space behaviour may be statically proved by type system and semantics.

These properties include both process equivalence and safety properties such as the absence of deadlock, livelock or resource starvation.

Hume consists of the expression layer and coordination layer, which share a common declaration language.

The expression layer is a purely functional, recursive language with strict semantics.

Based on concurrent finite state machines with transitions defined through pattern matching and recursive functions, the coordination layer is a finite state language.

The basic units of the coordination layer are boxes, with pattern matching transitions between inputs and outputs, and wires, which link boxes to each other and the external environment.

The coordination layer also provides exception-handling facilities including timeouts and system exceptions, and is responsible for interaction with the external environment through streams, associated with files or standard I/O, and ports, associated with devices.

The Hume design combines the desirable properties of abstraction and succinctness that are provided by a good functional programming language with a coordination layer that explicitly captures time and space behaviour.

An integrated tool set has been developed for proving and assessing concurrent, resource-limited systems, such as embedded or safety-critical systems.

%******************************************************************************%

\subsection{Hume Types}

All Hume type domains of are unpointed~\cite{Launchbury:Unpointed}, i.e. there is no explicit notion of an undefined value in each type domain.

The Hume types are \I{base} \I{types}, \I{structured} \I{types} and \I{exceptions} \I{types}.

The following are the three kinds of types that are supported by the Hume language and the operations.

The type \I{bit} is a synonym for {\I{word} 1}, and the type \I{byte} is a synonym for {\I{word} 8}.

%%% The conformance between base types is as shown in Table~\ref{tab:conformancy}.

%%% The most significant bit in a \I{word} is to the left.

%%% Base values are right aligned and left padded.

%%% Coerced structured types:

%%% \begin{itemize}

%%% \item must have the same number of elements at all levels

%%% \item are aligned top down, recursively, element by element left to right

%%% \end{itemize}

%Below is the set of fundamental types that are supported by the Hume language and the operations on these types.

\noindent\B{Base Types}

\begin{itemize}

\item

\I{bool}: boolean value

\item

\I{char}: 8 bit - ISO Latin-1 character

\item

\I{word} $<\I{size}>$: bits of specified size, in the range $0~{\ldots}~2^{n}-1$

\item

\I{int} $<\I{size}>$: 2's complement integer of specified bit size, in the range $-2^{n-1}~{\ldots}~2^{n-1}-1$

\item

\I{nat} $<\I{size}>$: natural number of specified bit size, in the range $0~{\ldots}~2^{n}-1$

\item

\I{float} $<\I{size}>$: floating point number of specified bit size (IEEE representation)

\item

\I{string} [$<\I{size}>$]: string of the specified length

\end{itemize}

\noindent\B{Structured Types}

\begin{itemize}

\item

\I{Vector}: fixed length sequence of uniform type with the given bounds.

\item

\I{Tuple}: fixed length sequence of mixed type.

\item

\I{List}: variable length sequence of uniform type.

\item

\I{Discriminated}~\I{union}: unions.

\end{itemize}

\noindent\B{Exceptions Types}

\begin{itemize}

\item

Declared by exception $<\I{id}>~<\I{type}>$ within declaration.

\item

Raised by raise $<\I{id}>~<\I{exp}>$ within expression.

\item

Handled by handle $<\I{handles}>$ within box.

\end{itemize}

There are lots of system predefined operations or functions and two kinds of type conversion.

Casting conversion treats a value as if it belonged to another equivalent type, when there is no loss of information when converting from a type to another type, or the conversion can be done with no runtime cost.

Its form is defined as $<\I{exp}>~::~<\I{type}>$.

If there may be loss of information and there may be also be a runtime cost, Hume uses the second type conversion, coercion.

The corresponding form is defined as $<\I{exp}>$ as $<\I{type}>$.

The basic operations are provided for each type.

There are some predefined system exceptions and user can define other exceptions.

%******************************************************************************%

\subsection{Hume Expression Layer}

Hume incorporates two layers, an expression layer and a coordination layer.

Its declaration language introduces types and values that scope over the expression layer and the coordination layer.

Following widely used functional languages, like Haskell~\cite{Haskell} \& SML~\cite{Milner:SML}, the Hume expression layer was defined as purely functional and has a strict evaluation order.

This allows tight cost functions to be derived for Hume expressions.

This allows a relatively simple semantics of exceptions to be specified as well.

Hume function applications have a strict semantics.

All arguments in function are evaluated from right-to-left before the function is called.

Hume expression layer supports predefined higher-order functions, polymorphism and inductive data structures.

Hume expression layer allows a user to define higher-order functions, recursive functions, and inductive data structure as well.

It is embedded in terms of function declarations and it is possible to define recursive and mutually recursive functions.

Expressions are defined as single, one-shot, non-reentrant processes through coordination layer constructs, and have statically provable properties.

This is achieved through appropriate type systems and formal semantics.

Hume supports two kinds of type declaration and either form of declaration supports polymorphism.

A number of type variable arguments, which may appear within the type declaration part, must be provided.

Constructed types may also be defined recursively.

%\begin{itemize}

% \item

% \B{The first form introduces a new constructed data type whose alternatives are distinguished by different data constructors (a discriminated union type).}

% \item

% \B{The second form introduces a type synonym; a named type equivalent to some pre-existing type.}

%\end{itemize}

For example, we can define a new type of polymorphic binary trees, and a version that is specialised to 32-bit integers, by:

\begin{verbatim}

data Tree a = Leaf a | Node (Tree a) (Tree a);

type IntTree = Tree (int 32);

\end{verbatim}

The following are the kinds of Hume expression:

\begin{itemize}

\item

Constants;

\item

Variables;

\item

Constructors: Used to build new data structures;

\item

Tuples, Lists and Vectors: User-defined types;

\item

Function Applications;

\item

Arithmetic and boolean expressions;

\item

Conditional expressions;

\item

Case expression with pattern matching;

\item

Recursive functions defined by case;

\item

Case Expressions;

\item

Local declarations;

\item

Type Expressions;

\item

Type Coercions: Type Conversions;

\item

Exceptions: System exceptions or user defined exceptions;

\item

Timeouts: the evaluation must complete within the specified constant time;

\item

Constant Expressions: It will be evaluated at compile-time.

\end{itemize}

%******************************************************************************%

\subsection{Hume Coordination Layer}

Comparing other functional language, the special point of Hume is its coordination layer.

The Hume coordination layer is a finite state notation for the description of multiple, interacting, reentrant processes, which are built from expressions, defined in the purely functional expression layer.

% \begin{itemize}

% \item \I{process}~\I{equivalence} and

% \item \I{safety} properties such as the absence of deadlock, livelock or resource starvation.

% the succinct term for the absence of unpleasantries, like

% deadlock, livelock and resource starvation, that commonly occur in

% multi-process systems;

% \end{itemize} Definitions in the coordination layer also inherit properties from exception expressions that are embedded within it.

%% I don't understand this! KH

The basic unit of coordination is the \I{box}, an abstract notion of a process that specifies the links between its input and output channels in terms of functional patterns and expressions, and which provides exception handling facilities including timeouts and system exceptions.

The coordination layer is responsible for interaction with external, imperative state through streams and ports that are ultimately connected to external devices.

Boxes and external input/output devices are \I{wired} into a static process network.

The coordination notation is designed to have statically provable properties for both \I{box} and \I{wire}.

%Hume also has a number of interesting design features.

%It incorporates both a very high level of abstraction (so simplifying the problem of proving correctness, and reducing the probability of introducing errors) with detailed and transparent cost models.

% The next section provides a detailed informal overview of the Hume language.

% The following sections provide overviews of the tool set, and the Hume Programme.

Hume boxes specify:

\begin{itemize}

\item

box name;

\item

names and types of inputs and outputs;

\item

input match patterns with associated outputs expressions;

\item

exception handling;

\item

timeout handling.

\end{itemize}

Hume wires specify:

\begin{itemize}

\item

connections between boxes;

\item

connections from boxes to input/outputs streams and ports;

\item

initial values for wires;

\end{itemize}

The rest of the coordination layer is consisted with:

\begin{itemize}

% \item

% Boxes: The Hume unit. It has a unique name and inputs and outputs. Each in or out has a unique name.

% \item

% Box Bodies: A set of matches.

% \item

% Exception Handlers: Define how to deal with exceptions.

% \item

% Wiring: Define boxes and streams and port connection.

\item

Box Templates and Instantiation: Define the structure of an abstract box.

\item

Wiring Macros: Can be used in a similar way to normal wiring declarations.

\item

Repeated Wiring: Repeat wiring declarations under the control of variable.

\item

Stream and Port Declarations: Define with what they are associated.

\item

Expression Macros: Can be used to construct simple compile-time macros.

\end{itemize}

%The macro notation enables the compile-time generalisation and repeated instantiation of boxes and wiring.

%******************************************************************************%

\subsection{Hume Execution Model}

Figure~\ref{fig:HEM} shows the HW-Hume execution model which is based on non-terminating, round-robin, one-shot scheduling of boxes.

\begin{figure}[htbp]

\centering

\begin{tabular}{|ll|}

\hline

1 & for each box \\

2 & \verb+ +state $\leftarrow$ RUNNABLE \\

3 & forever \\

4 & \verb+ +for each box\\

5 & \verb+ +if state != BLOCKED then\\

6 & \verb+ +state $\leftarrow$ MATCHFAIL\\

7 & \verb+ +for each match\\

8 & \verb+ +if some pattern matches input values then\\

9 & \verb+ +consume values from input wires\\

10 & \verb+ +evaluate associated expression\\

11 & \verb+ +generate output wires\\

12 & \verb+ +state $\leftarrow$ SUCCESS \\

13 & \verb+ +stop match loop\\

14 & \verb+ +for each box\\

15 & \verb+ +if state!=MATCHFAIL then\\

16 & \verb+ +if output wires can be established to their input wires then\\

17 & \verb+ +establish output wires\\

18 & \verb+ +state $\leftarrow$ RUNNABLE\\

19 & \verb+ +else\\

20 & \verb+ +state $\leftarrow$ BLOCKED \\

\hline

\end{tabular}

\caption{Hume Execution Model~\cite{Liu:Translating}}

\label{fig:HEM}

\end{figure}

%According to Hume Execution Model, when a Hume program executes.

At first, in line 1 and 2 is initial every box as \I{RUNNABLE}.

Then lines 4 {\textemdash} 20 starts the cycles.

Every cycle is split to two steps.

Lines 4 {\textemdash} 13 is the first step and are concurrently for running every box. % once concurrence.

Lines 14 {\textemdash} 20 is the second step.

It establishes wire input and output.

%******************************************************************************%

\subsection{Hume Language Levels}

\begin{figure}[htbp]

\centering

\includegraphics[]{Fig/Hume-Levels}

\label{fig:Hume:Hume-Levels}

\caption{Hume Levels~\cite{Michaelson:Hume:Report}}

\end{figure}

%Rather than attempting to apply cost modelling and correctness proving technology to an existing language framework either directly or by altering the language to a greater or lesser extent, Hume is designed in such a way that formal models and proofs can be constructed.

Showing in Figure~\ref{fig:Hume:Hume-Levels}, a series of overlapping Hume language levels can be identified, where each level adds expressibility to the expression semantics, but either loses some desirable behavioural property or increases the technical difficulty of providing formal correctness/cost models.

\begin{itemize}

\item

HW-Hume:

A hardware description language.

It is capable of describing both synchronous and asynchronous hardware circuits,

with pattern matching on tuples (maybe nested) of bits.

There is not any other data types or operations.

% In HW-Hume, types, patterns and values are restricted to possibly nested tuples of bits.

% However, this example is adequate for explaining the central features of our translation approach.

\item

FSM-Hume: A hardware/software language.

Adding first-order functions, conditionals expressions and local definitions to HW-Hume;

\item

Template-Hume: A language for template-based programming.

Adding predefined higher-order functions, polymorphism and inductive data structures to FSM-Hume.

But there are no user-defined higher-order functions or recursive function definitions.

\item

PR-Hume: A language with decidable termination.

Adding user-defined primitive recursive and higher-order functions,

and inductive data structure definitions to Template-Hume.

\item

Full-Hume: A Turing-complete language.

Adding unrestricted recursion in both functions and data structures to PR-Hume.

\end{itemize}

More description of these levels can be found elsewhere~\cite{HammKMichGV2006:ACMTSEMTOSEM}, including a description of how it is possible to transform programs from one level to another.

%******************************************************************************%

\subsection{A Hume Example: Full Adder} \label{sect:Adder}

The following program for the full adder is written in the HW-Hume language subset aimed at hardware descriptions.

It is based on the classic combination of two half adders with an \I{OR}, where each half adder is composed of an \I{AND} and an \I{XOR}.

The full adder is composed of two virtual half adders, which are each formed from a fanout box:

\begin{figure}[htbp]

\centering

\begin{tabular}{|c|c|c|c|c|}

\hline

x & y & c & z & c' \\

\hline

~ ~0~ ~ & ~ ~0~ ~ & ~ ~0~ ~ & ~ ~0~ ~ & ~ ~0~ ~ \\

~ ~0~ ~ & ~ ~1~ ~ & ~ ~0~ ~ & ~ ~1~ ~ & ~ ~0~ ~ \\

~ ~1~ ~ & ~ ~0~ ~ & ~ ~0~ ~ & ~ ~1~ ~ & ~ ~0~ ~ \\

~ ~1~ ~ & ~ ~1~ ~ & ~ ~0~ ~ & ~ ~0~ ~ & ~ ~1~ ~ \\

~ ~0~ ~ & ~ ~0~ ~ & ~ ~1~ ~ & ~ ~1~ ~ & ~ ~0~ ~ \\

~ ~0~ ~ & ~ ~1~ ~ & ~ ~1~ ~ & ~ ~0~ ~ & ~ ~1~ ~ \\

~ ~1~ ~ & ~ ~0~ ~ & ~ ~1~ ~ & ~ ~0~ ~ & ~ ~1~ ~ \\

~ ~1~ ~ & ~ ~1~ ~ & ~ ~1~ ~ & ~ ~1~ ~ & ~ ~1~ ~ \\

\hline

\end{tabular}

\caption{One Bit Full Adder}

\label{fig:addtable}

\end{figure}

\begin{figure}[htbp]

\centering

\includegraphics[]{Fig/Adder}

\caption{Full Adder~\cite{Liu:Translating}}

\label{fig:adder}

\end{figure}

\label{adder}

\begin{verbatim}

1 type Bit = int 1;

2 type Next = (Bit,Bit,Bit);

\end{verbatim}

Lines 1 and 2 introduce type aliases for one bit and a tuple of three bits.

\begin{verbatim}

3 box gen

4 in (t::Next)

5 out (t'::Next,x,y,c::Bit)

6 match

7 (0,0,0) -> ((0,0,1),0,0,0) |

8 (0,0,1) -> ((0,1,0),0,1,0) |

9 (0,1,0) -> ((0,1,1),1,0,0) |

10 (0,1,1) -> ((1,0,0),1,1,0) |

11 (1,0,0) -> ((1,0,1),0,0,1) |

12 (1,0,1) -> ((1,1,0),0,1,1) |

13 (1,1,0) -> ((1,1,1),1,0,1) |

14 (1,1,1) -> ((0,0,0),1,1,1);

\end{verbatim}

Lines 3 to 14 define a box to generate and log test cases.

\begin{verbatim}

15 template fanout

16 in (x,y::Bit)

17 out (x1,y1,x2,y2::Bit)

18 match

19 (x,y) -> (x,y,x,y);

20 instantiate fanout as f*2;

\end{verbatim}

Lines 15 to 19 define a box template to fanout two copies of

its inputs and line 20 instantiates two copies.

\begin{verbatim}

21 template xor

22 in (x,y::Bit)

23 out (z::Bit)

24 match

25 (0,0) -> 0 |

26 (0,1) -> 1 |

27 (1,0) -> 1 |

28 (1,1) -> 0;

29 instantiate xor as x*2;

\end{verbatim}

Lines 21 to 28 define an XOR box template and line 29 instantiates two copies.

\begin{verbatim}

30 template and

31 in (x,y::Bit)

32 out (z::Bit)

33 match

34 (0,0) -> 0 |

35 (0,1) -> 0 |

36 (1,0) -> 0 |

37 (1,1) -> 1;

38 instantiate and as a*2;

\end{verbatim}

Lines 30 to 38 define an AND box template and line 39 instantiates two copies.

\begin{verbatim}

39 box or

40 in (x,y::Bit)

41 out (z::Bit)

42 match

43 (0,0) -> 0 |

44 (0,1) -> 1 |

45 (1,0) -> 1 |

46 (1,1) -> 1;

\end{verbatim}

Lines 39 to 46 define an OR box.

\begin{verbatim}

47 box show

48 in (s,c::Bit)

49 out (sc::(Bit,Bit,char))

50 match

51 (s,c) -> (s,c,'\n');

\end{verbatim}

Lines 47 to 51 define a box to display the program output for each test case.

\begin{verbatim}

52 stream output to "std_out";

53 wire gen (gen.t' initially (0,0,0)) (gen.t,f1.x,f1.y,f2.x);

54 wire f1 (gen.x,gen.y) (x1.x,x1.y,a1.x,a1.y);

55 wire x1(f1.x1,f1.y1)(f2.y);

56 wire a1 (f1.x2,f1.y2)(or.x);

57 wire f2 (gen.c,x1.z) (x2.x,x2.y,a2.x,a2.y);

58 wire x2(f2.x1,f2.y1)(show.s);

59 wire a2 (f2.x2,f2.y2)(or.y);

60 wire or (a1.z,a2.z) (show.c);

61 wire show (x2.z,or.z) (output);

\end{verbatim}

Line 52 defines a stream linked to standard output.

Finally lines 53 to 61 wire the boxes to each other and to the stream.

As is clear from this example, it rapidly becomes difficult to understand the linear text of Hume programs composed of more than one or two boxes.

Comprehending individual boxes is relatively straightforward but envisaging the wiring of a whole program is somewhat more demanding.

Incidentally, if templates had not been used, this simple example would involve details of ten boxes and take up around 100 lines of text.

%******************************************************************************%

\section{HW-Hume Abstract Syntax}

We only introduce the HW-Hume abstract syntax.

Full Hume concrete syntax can be found in the Hume Report~\cite{Michaelson:Hume:Report}.

HW-Hume abstract and concrete syntax in Isabelle is in Chapter~\ref{chap:HI}.

\input{ChHL/AS}

Figure~\ref{fig:HL:AS} shows the abstract syntax of HW-Hume.

A HW-Hume program is built from one or more box(es),

one or more wire(s) and optional initial declarations,

const declarations and type declarations.

The program execution is independent of the order of box,

wire and init declarations.

The boxes can be concurrently executed in differently CPUs or hardware or different computers.

\label{239}

We use an example to explain ``$*$" (Ignore), ``{\_}" (Wild) and ``$\_*$" (Wild Ignore).

\begin{verbatim}

1 box explain

2 in (a,b,c,d::Bit)

3 out (x,y::Bit)

4 match

5 (*,_,_*,0) -> (*,1);

\end{verbatim}

In the box explain, the left ``$*$" in the match patten correspond to explain.a;

``$\_$" corresponds to explain.b;

``$\_*$" corresponds to explain.c;

``0" corresponds to explain.d;

the right ``$*$" in the match patten corresponds to explain.x;

``1" corresponds to explain.y.

When this box runs, it checks its input channels at first.

The left ``$*$" means the box does not check the wire link to explain.a.

``$\_$" means the box checks the wire link to explain.b.

If there is a value for explain.b, the matching of this wire succesed,

and the value will be removed when the matching of all wires of this box succesed.

``$\_*$" means the box checks the wire link to explain.c.

If there is a value for explain.c, it is the samed ``$\_$".

If there is not a value for explain.c, the matching of this wire still succesed.

The right ``$*$" means: when the box matches success,

it does not put any value to the wire linked to explain.x.

%******************************************************************************%

\section{HW-Hume Dynamic Semantics} \label{sect:HL:DS}

The Full-Hume formal semantics has been modelled in the Hume Report~\cite{Michaelson:Hume:Report}.

It followed Standard ML~\cite{Milner:SML} models,

that allow one to rigorously define the dynamic semantics using an axiomatic style.

For our aim, we only discuss HW-Hume formal dynamic semantics that is a subclass of Full-Hume formal semantics.

Before introducing Dynamic Semantics,

we assume that all static checks and translations that are defined by the static semantics are valid and have been properly carried out.

According to Hume syntax and executive model, we discuss notation, declarations, processes,

expressions and pattern matches of the HW-Hume operational semantics.

The current limitation on the HW-Hume dynamic semantics definition is only for the synchronous language (i.e.omitting fair matches and ``$*$").

However, we implemented HW-Hume dynamic semantics ``$*$",

but still omit fair matches in Chapter~\ref{chap:HI}.

%******************************************************************************%

\subsection{Dynamic Semantics: Notation}

The notation here is the same as the definition of Standard ML~\cite{Milner:SML}.

At first, we list the semantic domains and the notation.

The semantic domain is defined by \I{SemVal}.

The base value of HW-Hume (\I{BasVal}) is 0 $|$ 1.

Tuple is defined by $\Ang{\ldots}$ that enclose the \I{SemVal} domain.

This differs from the syntactic tuple domain,

and allows the direct representation of 1-tuples where necessary.

The notation $\I{D}^*$ is used to define the domain of all tuple of $\I{D}: ~\Ang{},~\Ang{\I{D}},~\Ang{\I{D},\I{D}},~{\ldots}$

\begin{figure}[htbp]

\centering

\begin{tabular}{|lclcll|}

\hline

& & \I{BasVal} & = & $\Bra{0~{\OR}~1}$ & {\quad} {\textemdash} Basic Values \\

\I{t},\I{v},\I{vs} & $\in$ & \I{SemVal} & = & $\I{BasVal}+\I{SemVal}^*+\I{matches}$ & {\quad} {\textemdash} Semantic Values \\

\I{E} & $\in$ & \I{Env} & = & $\Ang{\I{VarEnv},\I{SysEnv}}$ & {\quad} {\textemdash} Environments \\

\I{IE},\I{VE} & $\in$ & \I{VarEnv} & = & $\Bra{\I{var}~{\mapsto}~\I{SemVal}}$ & {\quad} {\textemdash} Value Environments \\

\I{SE} & $\in$ & \I{SysEnv} & = & $\Bra{\I{var}~{\mapsto}~\I{SemVal}^*}$ & {\quad} {\textemdash} System Environment \\

\I{b} & $\in$ & \I{bool} & = & $\Bra{\I{true},\I{false}}$ & {\quad} {\textemdash} Booleans \\

\I{W} & $\in$ & \I{Wire} & = & $\Bra{\I{var}~{\mapsto}~{\Ang{\I{var}^*,\I{var}^*}}}$ & {\quad} {\textemdash} Wires \\

\I{I},\I{A},\I{P} & $\in$ & \I{Process} & = & $\Bra{\I{Proc}}$ & {\quad} {\textemdash} Processes \\

& & \I{Proc} & = & $\Ang{\I{var},\I{SemVal}^*,\I{SemVal}^*,\I{exp}}$ & {\quad} {\textemdash} Process \\

\hline

\end{tabular}

\caption{HW-Hume Dynamic Semantics Notation}

\label{fig:HSem_Notation}

\end{figure}

Environments are a partial unique mapping from identifiers to values (\I{BasVal}, \I{SemVal}).

We can apply the environment to an identifier to get the corresponding entry in the map.

For example, if \I{E} is an environment with $\Bra{\I{var}~{\mapsto}~\I{v}}$, then $\I{E}~(\I{var})=\I{v}$.

The $\I{m}_{1}~{\combine}~\I{m}_{2}$ operation updates an environment mapping $\I{m}_{1}$ by the new mapping $\I{m}_{2}$.\\

i.e. when $\I{Domain}(m_1)~{\cap}~\I{Domain}(m_2)=\emptyset$, $\I{m}=\I{m}_{1}~{\combine}~\I{m}_{2}$

\begin{displaymath}

\I{m}~(\I{var})=

\left\{

\begin{array}{l}

\I{v},{\quad}\I{var}~{\in}~\I{Domain}(m_1),~ ~\I{m}_1(\I{var}) = \I{v} \\

\I{v},{\quad}\I{var}~{\in}~\I{Domain}(m_2),~ ~\I{m}_2(\I{var}) = \I{v}

\end{array}

\right.

\end{displaymath}

The $\I{m}_{1}~{\replace}~\I{m}_{2}$ operation is similar, but allows values in $\I{m}_{1}$ to be \I{shadowed} by those in $\I{m}_{2}$.

i.e.$\I{m}=\I{m}_{1}~{\replace}~\I{m}_{2}$ then

\begin{displaymath}

\I{m}~(\I{var})=

\left\{

\begin{array}{l}

\I{v},{\quad}\I{var}~{\in}~\I{Domain}(m_1),~ ~\I{var}~{\not\in}~\I{Domain}(m_2),~ ~\I{m}_1(\I{var})=\I{v} \\

\I{v},{\quad}\I{var}~{\in}~\I{Domain}(m_2),~ ~\I{m}_2(\I{var})=\I{v}

\end{array}

\right.

\end{displaymath}

The judgement form is $\I{E}~\vdash~\I{v}~{\Rightarrow}~\I{v}'$.

%******************************************************************************%

%\subsection{Dynamic Semantics: Initial Environment} \label{sect:HumeInit}

%The initial environment comprises definitions for constructors 0, 1.

%These values must be available in all HW-Hume programs.

%The initial environment contains the following predefined functions \Q{==} and \Q{!=} (\I{BasVal}).

%The mapping from syntactic variables to semantic constructors is the obvious one, that is, $\I{E}_{0}~(\I{SetEnv})=\I{SetEnv}~{\ldots}$.

%******************************************************************************%

\subsection{Dynamic Semantics: Declarations}

In the dynamic semantics, the environment is a mapping from identifiers to initial values.

Declarations are processed to generate an initial environment that is a mapping from identifiers to initial values.

This environment is used to determine the value of identifiers in variable expressions and to determine the value attached to an box's Input/Output object.

Declarations may be recursive (self or mutually).

\ruleheader{ \judgement {\I{E}} {\I{decls}} {\I{E}} }

Declarations generate initial environment.

\begin{itemize}

\item

%RULE (1)

Declarations: to generate initial environment from each declaration one by one.

\infrule

{ \label{rule:declarations} }

{ \OneToN, ~\judgement {\I{E}~{\combine}~{\C{j=1}{n}{\I{E}'_{j}}}} {\I{decl}_{i}} {\I{E}'_{i}} }

{ \judgement {\I{E}} {\I{decl}_{1}~{\ldots}~\I{decl}_{n}} {\I{E}~{\combine}~\Cin{\I{E}'_{i}}} }

{}

\end{itemize}

\ruleheader{ \judgement {\I{E}} {\I{decl}} {\I{VE}} }

Each declaration is processed to generate a corresponding value environment.

\begin{itemize}

\item

%RULE (2)

Constant declaration: to generate a constant variable.

\infrule

{ \label{rule:const-declaration} }

{ \judgement {\I{E}} {\I{exp}} {\I{v}} }

{ \judgement {\I{E}} {\B{constant}~\I{id}=\I{exp}} {\Bra{\I{id}~{\mapsto}~\I{v}}} }

{}

\item

%RULE (3)

Stream declaration (definition): to define an Input/Output stream.

\infrule

{ \label{rule:io-def} }

{ (\I{SE}~\I{of}~\I{E})~\I{id'}=\I{vs} }

{ \judgement {\I{E}} {\B{stream}~\I{id}~\B{from}/\B{to}~\I{id'}} {\Bra{\I{id}~{\mapsto}~\Ang{\I{true},\I{vs}}}} }

{}

\item

%RULE (4)

Stream declaration (initialisation): to initial an Input/Output stream.

\infrule

{ \label{rule:io-init} }

{ \judgement {\I{E}} {\I{cexp}} {\I{v}} {\quad} (\I{SE}~\I{of}~\I{E})~\I{id'}=\I{vs} {\quad} \I{vs'}={\Ang{\I{v},~\I{vs}}} }

{ \judgement {\I{E}} {\B{stream}~\I{id}~\B{from}~\I{id'}~\B{initially}~\I{cexp}} {\Bra{\I{id}~{\mapsto}~\Ang{\I{true},\I{vs'}}}} }

{}

\item

%RULE (5)

???delete? Matches definitions: to define matches.

\infrule

{ \label{rule:matches} }

{}

{ \judgement {\I{E}} {\I{var}~\I{matches}} {\Bra{\I{var}~{\mapsto}~\I{matches}}} }

{}

\item

%RULE (6)

???delete? Simple variable: to generate a variable.

\infrule

{ \label{rule:variable} }

{ \judgement {\I{E}} {\I{exp}} {\I{v}} }

{ \judgement {\I{E}} {\I{var}=\I{exp}} {\Bra{\I{var}~{\mapsto}~\I{v}}} }

{}

\end{itemize}

%******************************************************************************%

\subsection{Dynamic Semantics: Processes}

The dynamic semantics of the boxes that are defined in the program gives the dynamic semantics of a HW-Hume program.

This semantics is produced in the context of the declarations and wirings.

Wirings are specified in the program plus the initial environment of prelude bindings and imported values.

The result of a HW-Hume program is a new environment that reflects the state of new bindings in the system or value environments.

\ruleheader{ \judgement {\I{SE},\I{IE}} {\I{program}} {\I{E}} }

Program Definition.

\begin{itemize}

\item

%RULE (7)

Program: to generate a program.

\infrule

{ \label{rule:program} }

{

If the ``$*$" is implemented, the processes should not split.

For example, if there are two input channels \I{a} and \I{b} in a box, and only \I{b} is available.

The pattern $(*, \I{V})$ matches success, where ``$*$" matches \I{a} (``$*$" means ignore) and \I{V} matches \I{b}.

But the ``$*$" is omitted, nothing can match empty channel \I{a}.

That means: if not all input channels are available, the matching will fail.

Processing the matching is not needed at this situation.

In Chapter~\ref{chap:HI}, we implement the $*$, so we do not split the processes.

\begin{itemize}

\item

%RULE (12)

Split: to split the set of processes into active set and inactive set.

\infrule

{ \label{rule:io-Wire} }

{

\OneToN,~\judgement {\I{E},\I{W}} {\I{P}_{i}} {\I{I}_{i},\I{A}_{i}} {\quad}

\I{I}=\Uin{\I{I}_{i}} {\quad}

\I{A}=\Uin{\I{A}_{i}}

}

{ \judgement {\I{E},\I{W}} {\Bra{\I{P}_{1},~{\ldots},~\I{P}_{n}}} {\I{I},\I{A}} }

{}

\item

%RULE (13)

Determine: to determine one process is active or inactive.

\infrule

{ \label{rule:active-inactive} }

{

\begin{array}{c}

\I{P}=\Ang{\I{boxid},\I{ins},\I{outs},\I{body}} {\quad} \I{W}~(\I{boxid})=\Ang{\I{wins},\I{wouts}} \\

\judgement {\I{E}} {\I{wins}} {\I{b},\I{b'}} {\quad} \I{I},\I{A}=\I{if}~\I{b}~\V~\I{b'}~\I{then}~\Bra{},\Bra{\I{P}}~\I{else}~\Bra{\I{P}},~\Bra{}

\end{array}

}

{ \judgement {\I{E},\I{W}} {\Bra{\I{P}}} {\I{I},\I{A}} }

{}

\end{itemize}

\ruleheader{ \judgement {\I{E}} {\I{ids}} {\I{bool},\I{bool}} }

All input channels.

\begin{itemize}

\item

%RULE (14)

First input channel is active.

\infrule

\end{itemize}

\ruleheader{ \judgement {\I{E},\I{W}} {\I{P},\I{P}} {\I{E}} }

Processes are scheduled repeatedly until the set of active processes becomes empty.

\begin{itemize}

\item

%RULE (18)

To execute active processes.

\infrule

{ \label{rule:steps} }

{

\I{A}~\ne~{\Bra{}} {\quad}

\judgement {\I{E},\I{W}} {\I{I},\I{A}} {\I{E}',\I{I}',\I{A}'} {\quad}

\judgement {\I{E}',\I{W}} {\I{I}',\I{A}'} {\I{E}''}

}

{ \judgement {\I{E},\I{W}} {\I{I},\I{A}} {\I{E}'',\I{I}',\I{A}'} }

{}

\item

%RULE (19)

Termination: When there is no further active processes, the program terminates.

\infrule

{ \label{rule:termination} }

{}

{ \judgement {\I{E},\I{W}} {\I{I},\Bra{}} {\I{E}} }

{}

\end{itemize}

\ruleheader{ \judgement {\I{E},\I{W}} {\I{P},\I{P}} {\I{E},\I{P},\I{P}} }

Each active process is executed for one step and the output redirected to the input specified in the wiring specification.

All processes are then reassessed to determine their new activity status.

\begin{itemize}

\item

%RULE (20)

Execute all active processes.

\infrule

{ \label{rule:all-process} }

{

\begin{array}{c}

\OneTo{\card{\I{A}}},~\judgement {\I{E},\I{W}} {\I{A}_{i}} {\I{outs}_{i},~\I{E}^{I}_{i},\I{E}^{O}_{i}} \\

\I{E}'=\U{i=1}{\card{\I{A}}}{\I{E}^{I}_{i}}~{\replace}~\U{i=1}{\card{\I{A}}}{\I{E}^{O}_{i}} \\

\judgement {\I{E}~{\replace}~\I{E}',\I{W}} {\I{I}~\union~\I{A}} {\I{I}', \I{A}'}

\end{array}

}

{ \judgement {\I{E},\I{W}} {\I{I},\I{A}} {(\I{E}~{\replace}~\I{E}'),\I{I}',\I{A}'} }

{}

\end{itemize}

\ruleheader{ \judgement {\I{E}} {\I{P}} {\I{v},\I{E},\I{E}} }

A process is executed by determining the value of each of its inputs, and then executing the body of the process in the context of those values.

The new values of the inputs and outputs are returned.

\begin{itemize}

\item

%RULE (21)

Execute one active process.

\infrule

{ \label{rule:1-process} }

{

\begin{array}{c}

\I{W}~(\I{boxid})=\Ang{\I{wins},\I{wouts}} \\

\I{n}=\card{\I{wins}} \\

\I{SE}=\I{SE}~\I{of}~\I{E} \\

\I{vs}=\Ang{\snd{\I{SE}~(\I{wins}_{1}}),~{\ldots},~\snd{\I{SE}~(\I{wins}_{n}})} \\

\judgement {\I{E},\I{vs}} {\I{body}} {\I{vs}'} \\

\I{SE}^{I}=\Bra{\OneToN,~\I{wins}_{i}~{\mapsto}~{\Ang{\I{isport}~\I{wins}_{i},\I{tl}~\I{vs}_{i}}}} \\

\I{SE}^{O}=\Bra{\OneTo{\card{\I{wouts}}},~\I{wouts}_{i}~{\mapsto}~\Ang{\I{true},[\I{vs}'_{i}]}}

\end{array}

}

{ \judgement {\I{E},\I{W}} {\Ang{\I{boxid},\I{ins},\I{outs},\I{body}}} {\I{vs}',\I{SE}^{I},\I{SE}^{O}} }

{}

\end{itemize}

%The final set of process rules defines the semantics of executing a single box body.

%There are three cases, corresponding to normal execution, an exception or a timeout respectively.

%In order to implement fair matching, the new rule ordering returned by the match rule should update the definition of the matches for the box in the environment.

%In this way, each successful fair match will change the rule ordering, thereby ensuring that each rule is matched equally, as required by the semantics.

%******************************************************************************%

\subsection{Dynamic Semantics: Expressions}

\ruleheader{ \judgement {\I{E}} {\I{exp}} {\I{v}} }

The first few rules handle the semantics for simple expressions, including variables, basic values, nullary constructors.

\begin{itemize}

\item

Variables:

%RULE (22)

\infrule

{ \label{rule:expr-var} }

{ \I{E}~(\I{var})=\I{v} }

{ \judgement {\I{E}} {\I{var}} {\I{v}} }

{}

\item

Basic values:

%RULE (23)

\infrule

{ \label{rule:expr-const} }

{ \I{E}_{0}~(\I{b})=\I{exp} {\quad} \judgement {\I{E}} {\I{exp}} {\I{v}} }

{ \judgement {\I{E}} {\I{b}} {\I{v}} }

{}

%%-APPLICATIONS-%%

\item

A function application defines the semantics of function applications as the application of the body of the function to a tuple of the arguments.

There is no semantics of partial application.

%RULE (24)

\infrule

{ \OneToN,~\judgement {\I{E}} {\I{exp}_{i}} {\I{v}_{i}} {\quad} \judgement {} {\Ang{\I{v}_{1},~{\ldots},~\I{v}_{n}}} {\I{v}'} }

{ \judgement {\I{E}} {(~\I{exp}_{1}, ~{\ldots},~ \I{exp}_{n}~)} {\I{v}'} }

{}

\end{itemize}

%The final expression rules are used in constructing matches for case-expressions and function applications.

%If the expression to be matched is an exception, then the result of the match is an exception; otherwise the matching rules defined below are used.

%Since fair matching is never used for case-expressions, the reordered match list is discarded.

%******************************************************************************%

\subsection{Dynamic Semantics: Matches}

%For clarity, we use a different kind of turnstile ($\models$) for match inference rules.

%E,v~$\models$~e~$~{\Rightarrow}~$~v' defines the meaning of \I{match} with respect to a single matched value \I{e}.

%The semantics for definitions and applications ensures that matches are curried appropriately.

The semantics for pattern-matching is derived from that presented for Haskell~\cite{Haskell}.

This gives a less direct semantics than that of Standard ML.

Rules (\ref{rule:matches-succ} and \ref{rule:matches-fail}) define sequences of matches.

The first rule applies when the first match in a sequence succeeds, the second when it fails.

\ruleheader{ \judgement {\I{E},\I{v}} {\I{matches}} {\I{v}/\I{FAIL}} }

\begin{itemize}

\item

First match success:

%RULE (27)

\infrule

{ \label{rule:matches-succ} }

{ \judgement {\I{E},\I{v}} {\Bra{\I{match}}} {\I{v}'} }

{ \judgement {\I{E},\I{v}} {\Bra{\I{match}~{\OR}~\I{matches}}} {\I{v}'} }

{}

\item

First match failure:

%RULE (28)

\infrule

{ \label{rule:matches-fail} }

{ \judgement {\I{E},\I{v}} {\Bra{\I{match}}} {\I{FAIL}} {\quad} \judgement {\I{E},\I{v}} {\Bra{\I{matches}}} {\I{v}'} }

{ \judgement {\I{E},\I{v}} {\Bra{\I{match}~{\OR}~\I{matches}}} {\I{v}'} }

{}

\end{itemize}

\ruleheader{ \judgement {\I{E},\I{v}} {\I{match}} {\I{v}/\I{FAIL}} }

\begin{itemize}

\item

To simplify multi-argument matches to single-argument matches:

%Multi-Argument Matches

%RULE (29)

\infrule

{ \label{rule:match-multiple} }

{

\begin{array}{c}

\OneToM,~\I{var}_{i}~{\not\in}~(\U{j=1}{n}{\I{fv}(\I{pat}_{ij})}~\union~\I{fv}(\I{exp}_{i})) \\

\judgement

{\I{E},\I{v}}

{

\left\{

\begin{array}{l}

(\I{var}_{1},~{\ldots},~\I{var}_{n})~{\rightarrow}~\I{case}~(\I{var}_{1},~{\ldots}~,\I{var}_{n})~\I{of} \\

\begin{array}{l}

{\lbrace}

~~( \I{pat}_{11},{\ldots}, \I{pat}_{1n} )~{\rightarrow}~\I{exp}_{1} \\

~~~~| ~{\ldots}

~~~~| ~( \I{pat}_{m1},{\ldots}, \I{pat}_{mn} )~{\rightarrow}~\I{exp}_{m}

{\rbrace}

\end{array}

%RULE (30)

\infrule

{ \label{rule:match-simpl} }

{

\begin{array}{c}

\OneToN,~\I{var}_{i}~(\U{j=1}{n}{\I{fv}(\I{pat}_{j})~\union~\I{fv}(\I{exp}_{i})}) \\

\judgement

{\I{E},\I{v}}

{

\left\{

\begin{array}{l}

\I{pat}_{1}~{\rightarrow}~\I{exp}_{1} \\

|~\I{var}_{1}~{\rightarrow}~\mbox{case}~ \I{var}_{1} ~\mbox{of}~{\lbrace} \\

~~~~\I{pat}_{2}~{\rightarrow}~\I{exp}_{2} \\

~~~~|~\I{var}_{2}~{\rightarrow}~\mbox{case}~ \I{var}_{2} ~\mbox{of}~{\lbrace} \\

~~~~~~{\ldots} \\

~~~~~~|~\I{var}_{n-1}~{\rightarrow}~\mbox{case}~ \I{var}_{n-1} ~\mbox{of}~{\Bra{ \I{pat}_{n}~{\rightarrow}~\I{exp}_{n}}} {\ldots}{\Bra{}}

\end{array}

\right\}

}

{\I{v}'}

\end{array}

}

{ \judgement {\I{E}, \I{v}} {\Bra{\I{pat}_{1}~{\rightarrow}~\I{exp}_{1} ~| {\ldots} |~ \I{pat}_{n}~{\rightarrow}~\I{exp}_{n}}} {\I{v}'} }

{ \I{n}~\geq~1 }

\item

Wildcard matches:

%(_ -> e1; _ -> e2 == _ -> e1)

%RULE (31)

\infrule

{ \label{rule:match-wildcard} }

{ \judgement {\I{E}} {\I{exp}} {\I{v}'} }

{ \judgement {\I{E},\I{v}} {\Bra{{\UDS}~{\rightarrow}~\I{exp}}} {\I{v}'} }

{}

\item

Variable matches:

%(var -> e binds v to matched value)

%RULE (32)

\infrule

{ \label{rule:match-var} }

{ \judgement {\I{E}~{\replace}~\Bra{\I{var}~{\mapsto}~\I{v}}} {\I{exp}} {\I{v}'} }

{ \judgement {\I{E},\I{v}} {\Bra{\I{var}~{\rightarrow}~\I{exp}}} {\I{v}'} }

{}

\item

Const matches success:

%(var -> e binds v to matched value)

%RULE (33)

\infrule

{ \label{rule:match-const} }

{ \judgement {\I{E}} {\I{exp}} {\I{v}} {\quad} \I{C}_1 = \I{C}_2 }

{ \judgement {\I{E},\I{C}_1} {\Bra{\I{C}_2~{\rightarrow}~\I{exp}}} {\I{v}} }

{}

\item

Const matches fail:

%(var -> e binds v to matched value)

%RULE (34)

\infrule

{ \label{rule:match-const-fail} }

{ \I{C}_1 \not= \I{C}_2 }

{ \judgement {\I{E},\I{C}_1} {\Bra{\I{C}_2~{\rightarrow}~\I{exp}}} {\I{FAIL}} }

{}

\item

The semantics of matches against constructor patterns is:

%Rules (~\ref{rule:constr-match-simplify}) and (~\ref{rule:tuple-match-simplify}) are simplification rules, simplifying general constructor matches and tuple matches, respectively; the remaining rules define the matching semantics.

%The simplification rules are used to simplify deep pattern matches (such as [1,2]) into single-level matches.

%Tuple Simplification

%RULE (35)

{\I{v}'}

}

\end{array}

}

{ \judgement {\I{E},\I{v}} {\Bra{(\I{pat}_{1},{\ldots},\I{pat}_{n})~{\rightarrow}~\I{exp}}} {\I{v}'} }

{}

\item

Tuple matches:

%RULE (36)

\infrule

{ \label{rule:tuple-matches} }

{ \I{v}=\Ang{\I{v}_{1},~{\ldots},~\I{v}_{n}} {\quad} \judgement {\I{E}~{\replace}~\Uin{\Bra{\I{var}_{i}~{\mapsto}~\I{v}_{i}}}} {\I{exp}} {\I{v}'} }

{ \judgement {\I{E},\I{v}} {\Bra{(~\I{var}_{1},~{\ldots},~\I{var}_{n}~)~{\rightarrow}~\I{exp}}} {\I{v}'} }

{}

\end{itemize}

%******************************************************************************%

\label{242}

\subsection{Related Research on Hume} \label{sect:HumeResearch}

Michaelson et al~\cite{Michaelson:FSM03,Michaelson:FSM05} discussed how a single box FSM-Hume program is a finite state machine.

Multi-box FSM-Hume program can be translated to an equivalent single box.

So a multi-box FSM-Hume program is a finite state machine as well.

Based on automata theory, FSM-Hume is decidable.

HW-Hume is a subclass of FSM-Hume, so HW-Hume is decidable.

Hume has been designed to support bounded time and space behaviour,

Hammond~\cite{BoneAChenZHMWW2007:ACM} developed a cost model using a formal descriptive semantics.

It is integrated with a simple static time analysis for first-order programs.

This semantics covers coordination layer, unusual expression layer,

exception handling and pattern matching.

We develop HW-Hume Big Step operational semantics in Isabelle/HOL in Chapter~\ref{chap:HI}.

That is running in a pure logic virtual machine.

%******************************************************************************%

\section{Summary}

This chapter we have introduce the Hume Language,

HW-Hume dynamic operational semantics and relevant research on Hume.

They are mainly Hammond and Michaelson's work.

Our HW-Hume Big Step operational semantics in Isabelle/HOL in Chapter~\ref{chap:HI} is based on the exist HW-Hume dynamic operational semantics.

Our Service Portfolio

Want To Place An Order Quickly?

Then shoot us a message on Whatsapp, WeChat or Gmail. We are available 24/7 to assist you.

Do not panic, you are at the right place

Visit Our essay writting help page to get all the details and guidence on availing our assiatance service.

Get 20% Discount, Now
£19 £14/ Per Page
14 days delivery time

Our writting assistance service is undoubtedly one of the most affordable writting assistance services and we have highly qualified professionls to help you with your work. So what are you waiting for, click below to order now.

Get An Instant Quote

ORDER TODAY!

Our experts are ready to assist you, call us to get a free quote or order now to get succeed in your academics writing.

Get a Free Quote Order Now