From 9ce3bc07fc567594c0ceb22386799ec59e9dfdd7 Mon Sep 17 00:00:00 2001
From: Alfie Eagleton <67986414+TheAlfanator@users.noreply.github.com>
Date: Sat, 16 Oct 2021 17:16:21 +0100
Subject: 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
---
 report/esoteric_project_report.tex | 36 ++++++++++++++++++++++--------------
 1 file changed, 22 insertions(+), 14 deletions(-)

(limited to 'report/esoteric_project_report.tex')

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}
-- 
cgit v1.2.3


From b49bb78db545f0aa6569d8e78e79d4740ca77c4a Mon Sep 17 00:00:00 2001
From: Alfie Eagleton <67986414+TheAlfanator@users.noreply.github.com>
Date: Sun, 17 Oct 2021 17:53:14 +0100
Subject: Chapter 3 - FORTRAN

Created a grammar table regarding FORTRAN and Java.
---
 report/esoteric_project_report.tex | 66 ++++++++++++++++++++++++++++++++++++++
 1 file changed, 66 insertions(+)

(limited to 'report/esoteric_project_report.tex')

diff --git a/report/esoteric_project_report.tex b/report/esoteric_project_report.tex
index 8306b94..055f752 100644
--- a/report/esoteric_project_report.tex
+++ b/report/esoteric_project_report.tex
@@ -79,6 +79,72 @@ Esolangs are programming languages designed to be jokes or proof of concept lang
 \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{Grammar - FORTRAN}
+
+\section {Why we chose FORTRAN}
+
+asdf
+
+\begin{table}[h!]
+	\begin{center}
+		
+		\begin{tabular}{|l|r|}
+			\hline
+			\textbf{Token} & \textbf{Replaces}\\
+			\hline
+			! & \slash\slash \\
+			\hline
+			PROGRAM x & public class x \{ \\
+			\hline
+			END PROGRAM & \} \\
+			\hline
+			INTEGER & int \\
+			\hline
+			LOGICAL & boolean \\
+			\hline
+			.FALSE. & false \\
+			\hline
+			.TRUE. & true \\
+			\hline
+			CHARACTER(LEN=x) & String \\
+			\hline
+			:: & = \\
+			\hline
+			IF (x) THEN & if(x) \{ \\
+			\hline
+			ELSE & else \\
+			\hline
+			END IF & \} \\
+			\hline
+			SELECT CASE (x) & switch(x) \{ \\
+			\hline
+			CASE (x) & case x: \\
+			\hline
+			CASE DEFAULT & default: \\
+			\hline
+			END SELECT & \} \\
+			\hline
+			x & x; \\
+			\hline
+			DO x = y, z & for(x = y, x < z; x++) \{ \\
+			\hline
+			END DO & \} \\
+			\hline
+			PRINT *, x & System.out.println(x); \\
+			\hline
+			SUBROUTINE x & static void x() \{ \\
+			\hline
+			END SUBROUTINE & \} \\
+			\hline
+			CALL x & x(); \\
+			\hline
+		
+		\end{tabular}
+		\label{tab:table1}
+		\caption{Grammar table for Fortran}
+	\end{center}
+\end{table}
+
 \chapter{Methodology}\label{MethLab}
 
 Describe here various methods that will be used in your project. Use different sections for distinctly different subjects and use subsections for specific details on the same subject. Only use subsubsections or paragraphs (which are not numbered) if you believe this is really necessary. Since implementation will happen in sprints, this section may need several updates with parts being added and deleted across the project.
-- 
cgit v1.2.3


From 8d0f7e7ac306e6c49cfd5735417b0a8b78c98f34 Mon Sep 17 00:00:00 2001
From: chris-sutcliffe <ctd.sutcliffe@gmail.com>
Date: Sun, 17 Oct 2021 21:26:07 +0100
Subject: change report structure slightly, add subheadings

---
 report/esoteric_project_report.tex | 10 +++++++---
 1 file changed, 7 insertions(+), 3 deletions(-)

(limited to 'report/esoteric_project_report.tex')

diff --git a/report/esoteric_project_report.tex b/report/esoteric_project_report.tex
index 8306b94..d1326b7 100644
--- a/report/esoteric_project_report.tex
+++ b/report/esoteric_project_report.tex
@@ -68,12 +68,16 @@ Breifly describe what you will cover in the remainder of the report, chapter by
 \chapter{Research of Similar Systems}
 
 \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.   
+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. 
 
-\section{Programming Languages}
+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{Interpreted 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}
+\section{Esoteric Languages (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}
-- 
cgit v1.2.3


From 3c3706a8957f27d7bcb553eff6ded1c6dc76fa24 Mon Sep 17 00:00:00 2001
From: chris-sutcliffe <ctd.sutcliffe@gmail.com>
Date: Mon, 18 Oct 2021 15:43:54 +0100
Subject: add some notes on grammar and start lexer section

---
 report/esoteric_project_report.tex | 61 +++++++++++++++++++++++++++++++++++++-
 1 file changed, 60 insertions(+), 1 deletion(-)

(limited to 'report/esoteric_project_report.tex')

diff --git a/report/esoteric_project_report.tex b/report/esoteric_project_report.tex
index 25491d5..788226a 100644
--- a/report/esoteric_project_report.tex
+++ b/report/esoteric_project_report.tex
@@ -83,7 +83,66 @@ Esolangs are programming languages designed to be jokes or proof of concept lang
 \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{Grammar - FORTRAN}
+\chapter{The Structure of our Programming Language}
+\section{The Lexar (Lexical Analysis)} 
+In the field of linguistics or computer programming language design, lexical analysis is the process of converting a sequence of characters (such as a computer program) into a sequence of tokens. 
+This process is also known as tokenisation, particularly in the field of natural language processing (NLP).
+When designing a programming language, the task of lexical analysis or tokenisation is performed by a lexer. 
+The actual matching of tokens is often performed using regular expressions, defined in the design stage in order to reliably match all tokens in the language. 
+
+
+\chapter{Grammar}
+
+
+\section{Introduction to Language Grammar}
+\begin{verbatim}
+
+Work in progress currently
+
+\end{verbatim}
+Context free grammars – something = something else 
+
+Context free because there is no rule or context about where this grammar belongs, only where it goes
+
+Rewrite rules:
+S $\rightarrow$ DET N
+Were first invented by Panini %Pāṇini
+ who worked on Sanscrit grammar rules
+ 
+Port Royal Grammer by Antoine Arnauld and Claude Lancelot in 1660 who worked at Port-Royal-des-Champs
+
+then Ferdinand de Saussure (19th century)
+
+then Chomsky with Chomsky hierarchy.
+
+
+BNF form (Backus Naur form)  is a meta language for grammars
+Named after the people who invented it simultaneously 
+example:
+\begin{verbatim}<program> ::= <sequence>? 
+\end{verbatim}
+This means a program consists of a sequence of allowable grammars followed by question mark
+Can be read as “program consists of a sequence of things followed by question mark”
+
+
+Grammar consists of a series of rewrite rules
+Grammar is a quadruple. It is a set of:
+\begin{itemize}
+	\item Terminal symbols
+	\item Non terminal symbols
+	\item Set of rules
+	\item Start symbol (one of the non-terminal symbols)	
+\end{itemize}
+
+
+Any regular grammar can be recognised by regular expressions (refer to regular grammar in Chomksy hierarchy)
+
+After Chomsky came Backus and Naur – BNF 
+
+Niklaus Wirth – Pascal language
+
+Dijkstra – programming without goto (gotoless programming)
+
 
 \section {Why we chose FORTRAN}
 
-- 
cgit v1.2.3

