Report Writing

I implemented the existing bullet pointed intro document into a fuilly written report.tex file, then merged into esoteric_project_report.text under Chapter 1 and Chapter 2

3 files changed, 61 insertions, 14 deletions

diff --git a/report/esoteric_project_report.pdf b/report/esoteric_project_report.pdf
index db4a8c1..67ff856 100644
--- a/report/esoteric_project_report.pdf
+++ b/report/esoteric_project_report.pdf
diff --git a/report/esoteric_project_report.tex b/report/esoteric_project_report.tex
index 2f20a7e..8306b94 100644
--- a/report/esoteric_project_report.tex
+++ b/report/esoteric_project_report.tex
@@ -43,31 +43,41 @@
 
 
 \begin{abstract}
-An abstract is a brief summary (maximum 250 words) of your entire project. It should cover your objectives, your methodology used, how you implemented the methodology for your specific results and what your final results are, your final outcome or deliverable and conclusion. You do not cover literature reviews or background in an abstract nor should you use abbreviations or acronyms. In the remainder of the report the chapter titles are suggestions and can be changed (or you can add more chapters if you wish to do so). This template is designed to help you write a clear report but you are welcome to modify it (at your peril ...). Finally, a guideline in size is approximately 3,500 words (not including abstract, captions and references) but no real limit on figures, tables, etc.
+ABSTRACT INCOMPLETE
 \end{abstract}
 
 \chapter{Introduction}
 \label{chap:intro}
+For this project we have decided to create an Esolang interpreter in Java so that we can write code, craft Boolean expressions and calculate Math. We plan to research, design and implement an esoteric language while also understanding fundamental advanced programming concepts.
 
-The introduction should be brief and comprise the following:
+\section{Functional Requirements}
+After some discussion, we decided that our goals for this project are to create grammar for a language and form a lexical analysis algorithm. After this, we may develop a parser or interpreter so that we can convert our high level code into bytecode which can be read more easily by the JVM.
 
-\section{Project statement}
-A (brief) statement including the nature of the project, i.e.\ what you will do, how you will accomplish it and what the final deliverable will be.
+\section{Non-functional Requirements}
+Our code should be well tested, and be capable of handling edge cases. It should be modular and scalable so that functionality can easily be added without undue difficulty. It would be good if our interpreter could calculate mathematical functions and have good performance with well optimized code.
 
-\section{MoSCoW}
+\section{Technology}
+We are looking at coding Java in IntelliJ, and potentially using GNU Bison to parse.
 
-Specify the Must-Should-Could-Won't functionality of your software product.
-Besides the usual itemised list (or table) you may also add a text clarifying as to why certain items are more important or why certain items will not make it to the final deliverable. A MoSCoW does not need to be complete early on in the project and can be updated well into the project though conversely, it should neither be reversely specified at the end of the project to match the final deliverable!
+\section{MoSCoW Analysis}
+We thought about what our interpreter may or may not have so that we have a clear understanding of our priorities when coding. We decided that our software \emph{must} read and interpret commands immediately from a command line. The language \emph{must} be Turing complete, and be capable of detecting syntax and runtime errors. It \emph{should} be able to read from file and execute a script. It also \emph{should} be able to optimize source code during runtime. The interpreter \emph{could} be able to implement functions and procedures with return values, and be able to handle memory allocation and disposal. Our program \emph{won't have} a graphical or web-based interface, since it would take up too much development time and is not entirely needed for the scope of this project. It also will not implement object-oriented programming features.
 
 \section{Report structure}
 Breifly describe what you will cover in the remainder of the report, chapter by chapter.
 
-\chapter{Background}
+\chapter{Research of Similar Systems}
 
-Depending on the nature of the project, this chapter may cover a literature, resource and/or (software) product review. For a literature review you will consult journal or conference papers outlining methodologies that you may (or may not) use but which are definitely relevant to your particular problem. Resource and/or product information will typcially be substantiated through internet links. 
-You may use different sections if different subareas are part of your problem statement and/or solution. 
-Since this chapter covers background resources, you should also update the corresponding bib file referred to in the bottom of this document and here it is called References.bib.
-You cite references like this: Taylor et al. \cite{Taylor:2007} investigated non-linear FEA on the GPU. Morton \cite{Morton:1966} developed a file sequencing method in 1966. A website on OpenCL can be found here \cite{Soos:2012}. Etc.
+\section{Compilers vs Interpreters}
+Within the field of computer programming languages, there are two main types: compiled languages and interpreted languages. Both of these styles have distinct advantages and disadvantages. Compilers and interpreters both convert code written in human readable higher-level languages to instructions that a computer can execute. In the case of compiler, code is converted from high level program code to assembly language then to machine language. This process can be slow, especially when there is a large amount of code to compile, but execution is fast as only the instructions directly executed are required to be kept in memory. In contrast to this, Interpreter directly runs the code given to it, or in other words, an interpreter is a separate program that reads and executes the instructions itself, rather than converting them into the assembly language of that particular architecture being run on. The principal advantage of this is that a computationally expensive compilation process does not have to be run every time, therefore leading to faster startup times. However, this approach carries with it a big disadvantage, namely that because every line has to be interpreted, execution is slower than the equivalent instructions run in a compiled language.   
+
+\section{Programming Languages}
+There are a number of prominent interpreted languages in use today, including Python, Matlab, Perl, Ruby and PHP. All of these languages have interpreters that are written in C or C++, which are compiled languages. The interpreters for each language are loaded into memory, along with an instruction that they then interpret.  
+
+\section{Esolangs}
+Esolangs are programming languages designed to be jokes or proof of concept languages, rather than those to be used in actual programming tasks. Typically, the reason they are created is for fun rather than any serious desire to solve a particular programming problem, and so most languages aim to be funny, to be as difficult to use as possible or to have few features while still being Turing complete.   
+
+\section{Example - Shakespearian Programming Language}
+The Shakespeare Programming Language is esoteric code parodied on extracts from Romeo and Juliet. Here, code is written so it reads like how a script would, such as \texttt{[Enter Juliet]} where \texttt{Juliet} may be a variable name. Other examples include using \texttt{Acts} or \texttt{Scenes} as GOTO statements, where the interpreter can jump to a certain point in the code and read from there. Otherwise, these are ignored similar to the title or character descriptions. Other examples include LOLCODE, Hodor or White Space. This serves the purpose of writing code in a different manner to usual, sometimes for humour. The aim is to replace typical language features so that it can still be read by a compiler or interpreter but also look and read very differently by the user.  
 
 \chapter{Methodology}\label{MethLab}
 
@@ -116,7 +126,6 @@ The purpose of this section is to just show you how to integrate figures, tables
 
 \begin{figure}[htb]
 %\begin{center}
-\includegraphics[width=1.0 \columnwidth]{pelvis_octree.png}
 \caption{The bony pelvis model with octree based AABBs (Axis Aligned Bounding Boxes).}
 \label{Pelvis_BVH}
 %\end{center}
@@ -126,7 +135,6 @@ Fig.\ \ref{class} shows a UML class diagram (class, sequence and state diagrams
 
 \begin{figure}[htb]
 %\begin{center}
-\includegraphics[width=1.0 \columnwidth]{class.png}
 \caption{A UML class diagram.}
 \label{class}
 %\end{center}
diff --git a/report/report.tex b/report/report.tex
new file mode 100644
index 0000000..c35bd0e
--- /dev/null
+++ b/report/report.tex
@@ -0,0 +1,39 @@
+\documentclass[12pt]{scrartcl}
+\title{Advanced Programming Esoteric Project}
+\author{Alfie Eagleton 100274245\\Eden Attenborough 100301654\\Aiden Rushbrooke 100235483\\Chris Sutcliffe 100228212}
+
+\begin{document}
+	
+\maketitle
+\clearpage
+
+\section{Introduction \& Objectives}
+For this project we have decided to create an Esolang interpreter in Java so that we can write code, craft Boolean expressions and calculate Math. We plan to research, design and implement an esoteric language while also understanding fundamental advanced programming concepts.
+
+	
+\section{Functional Requirements}
+After some discussion, we decided that our goals for this project are to create grammar for a language and form a lexical analysis algorithm. After this, we may develop a parser or interpreter so that we can convert our high level code into bytecode which can be read more easily by the JVM.
+
+\section{Non-functional Requirements}
+Our code should be well tested, and be capable of handling edge cases. It should be modular and scalable so that functionality can easily be added without undue difficulty. It would be good if our interpreter could calculate mathematical functions and have good performance with well optimized code.
+
+\section{Technology}
+We are looking at coding Java in IntelliJ, and potentially using GNU Bison to parse.
+
+\section{MoSCoW Analysis}
+We thought about what our interpreter may or may not have so that we have a clear understanding of our priorities when coding. We decided that our software \emph{must} read and interpret commands immediately from a command line. The language \emph{must} be Turing complete, and be capable of detecting syntax and runtime errors. It \emph{should} be able to read from file and execute a script. It also \emph{should} be able to optimize source code during runtime. The interpreter \emph{could} be able to implement functions and procedures with return values, and be able to handle memory allocation and disposal. Our program \emph{won't have} a graphical or web-based interface, since it would take up too much development time and is not entirely needed for the scope of this project. It also will not implement object-oriented programming features.
+
+\section{Similar systems and Research}
+\subsection{Compilers vs Interpreters}
+Within the field of computer programming languages, there are two main types: compiled languages and interpreted languages. Both of these styles have distinct advantages and disadvantages. Compilers and interpreters both convert code written in human readable higher-level languages to instructions that a computer can execute. In the case of compiler, code is converted from high level program code to assembly language then to machine language. This process can be slow, especially when there is a large amount of code to compile, but execution is fast as only the instructions directly executed are required to be kept in memory. In contrast to this, Interpreter directly runs the code given to it, or in other words, an interpreter is a separate program that reads and executes the instructions itself, rather than converting them into the assembly language of that particular architecture being run on. The principal advantage of this is that a computationally expensive compilation process does not have to be run every time, therefore leading to faster startup times. However, this approach carries with it a big disadvantage, namely that because every line has to be interpreted, execution is slower than the equivalent instructions run in a compiled language.   
+
+\subsection{Programming Languages}
+There are a number of prominent interpreted languages in use today, including Python, Matlab, Perl, Ruby and PHP. All of these languages have interpreters that are written in C or C++, which are compiled languages. The interpreters for each language are loaded into memory, along with an instruction that they then interpret.  
+
+\subsection{Esolangs}
+Esolangs are programming languages designed to be jokes or proof of concept languages, rather than those to be used in actual programming tasks. Typically, the reason they are created is for fun rather than any serious desire to solve a particular programming problem, and so most languages aim to be funny, to be as difficult to use as possible or to have few features while still being Turing complete.   
+
+\subsection{Example - Shakespearian Programming Language}
+The Shakespeare Programming Language is esoteric code parodied on extracts from Romeo and Juliet. Here, code is written so it reads like how a script would, such as \texttt{[Enter Juliet]} where \texttt{Juliet} may be a variable name. Other examples include using \texttt{Acts} or \texttt{Scenes} as GOTO statements, where the interpreter can jump to a certain point in the code and read from there. Otherwise, these are ignored similar to the title or character descriptions. Other examples include LOLCODE, Hodor or White Space. This serves the purpose of writing code in a different manner to usual, sometimes for humour. The aim is to replace typical language features so that it can still be read by a compiler or interpreter but also look and read very differently by the user.  
+
+\end{document}
\ No newline at end of file