\documentclass[report.tex]{subfiles}
\begin{document}

\section{Progress} % (fold)
\label{cha:progress}

\subsection{The Q'Grady Language} % (fold)
\label{sub:the_q_grady_language}
After helpful direction from my supervisor Ross, I have a basic language that is
being used for the development of the compiler. The thought process behind this
language is keeping things as simple as possible, focusing on the probability
distribution part of the language. My original language designs were a vast
over-complication of the task at hand.

At this point in time, a basic Q'Grady file representing the Popescu-Rohrlich
(or PR) box:

\begin{verbatim}
        [0.5, 0, 0, 0.5; 0.5, 0, 0, 0.5; 0.5, 0, 0, 0.5; 0, 0.5, 0.5, 0;]
\end{verbatim}

\subsubsection{Syntax} % (fold)
The BNF for the Q;Grady syntax is defiend as below:
\begin{verbatim}

<box>  ::= `[' <list> `]';
<list> ::= | <list> <row>;
<row>  ::= <decimal> <dist> `;';
<dist> ::= | <dist> `,' <decimal>;
\end{verbatim}

This BNF allows for the representing of the probability distribution with each
row easily identifiable. Currently, there is no syntax that allows for the
explicit defining of the parties, inputs or outputs of this set-up.

One peculiarity of the current syntax are the empty choices in the \textless
list \textgreater and\textless dist\textgreater lines. This was not an original
decision as part of the design language, and was instead a result of constraints
in the CUP syntax (see \ref{sub:the_q_grady_compiler}).
\label{ssub:syntax}

% subsubsection syntax (end)

\subsubsection{Semantics} % (fold)
\label{ssub:semantics}
Currently, the semantics of the language are a lot more informal in comparison
to the syntax. This was due to difficulties in understanding formal denotational semantics, so fully formalising the language was put aside in favour of starting
the development of the compiler.

The box is a conditional probability distribution that satisfies non-signalling.
Each row is a list of the probabilities of each outcome based on the given
input. For the PR example, the first line would represent p(ab\textbar00).
% subsubsection semantics (end)
% subsection the_q_grady_language (end)

\subsection{The Q'Grady Compiler} % (fold)
\label{sub:the_q_grady_compiler}
So far the compiler is capable of taking in a file and determining whether:
\begin{itemize}
    \item It is a valid .qgrady file (the file exists and has .qgrady extension)
    \item Uses the the Parser and Scanner generators created using CUP and JFlex
    to ensure that the syntax of the language is maintained.
    \item Semantic checks on the extracted matrix to ensure that the following
    conditions are met:
    \begin{itemize}
        \item Each row of probabilities are of equal length.
        \item Each row of probabilities sums up to exactly 1.
        \item Each probability is between 0 and 1.
    \end{itemize}
\end{itemize}

Working with CUP and JFlex had some issues due to what I felt was not excellent
documentation and examples. For example, the way CUP handled recursion in the
grammar (as mentioned in \ref{ssub:syntax}) required the unintuitive BNF based
on the examples the library provides.

Another issue encountered with CUP was that while I was wanting to use a
primitive two-dimensional array for storing the distribution, I had to use the
ArrayList class since I would be unable to predict the size required for the
array.

The Java classes generated by CUP and JFlex have given me cause for concern due
to the unreadable code that is produced from the libraries. While the files do
indeed work, it makes it difficult to truly gain an appreciation of the
libraries when the code produced can only be described as a mess.

While I am able to extract p(ab\textbar xy), I have had issues extracting
p(a\textbar x) from the distribution. I have not yet found the best way to
truly represent the distribution in such a way that this will become easier.
This is required in order to produce a check for non-signalling that needs done
before I go into the code generation phase of the compiler.
% subsection the_q_grady_compiler (end)

\subsection{The Q'Grady Report} % (fold)
\label{sub:the_q_grady_report}
Since my focus has been on development (as agreed upon in meetings with my
supervisor), not much focus has been made on the writing side of the report.
However, I still have an outline of the division of the document, providing me
a preliminary breakdown of the report which should make writing easier.
% subsection the_q_grady_report (end)
\subsection{Future Plans} % (fold)
\label{sub:future_plans}
I don't expect a massive diversion from my previous plans. By the end of Week 4
I am to have the non-signalling check implemented (and all the features required
for it), this would allow me two more weeks to work towards developing the
compiler. It might be the case where I need the first week of March for
development as well, although I will be hoping to avoid this if possible.
% subsection future_plans (end)
% section progress (end)
\newpage
\end{document}