# publichardselius/cpc-dsl

### Subversion checkout URL

You can clone with HTTPS or Subversion.

• 6 commits
• 7 files changed
• 1 contributor
May 07, 2012
advances in dataflow programming languages a5700e0
changed version numbering dc49a98
\nocite{*} e545c36
minor changes ba9832f
more on programming paradigms 46be9f5
Merge branch 'master' of github.com:hardselius/cpc-dsl db94efa
35  thesis/Bibliography.bib
 @@ -156,7 +156,7 @@ @Misc{spark:online 156 156   157 157  @Misc{yapps:online,  158 158  OPTkey = {},  159 - OPTauthor = {},  159 + author = {Patel, Amit},  160 160  title = {{YAPPS} ({Y}et {A}nother {P}ython {P}arser  161 161  {S}ystem)},  162 162  howpublished = {\url{http://theory.stanford.edu/~amitp/yapps/}},  @@ -166,3 +166,36 @@ @Misc{yapps:online 166 166  OPTannote = {}  167 167  }  168 168   169 +@Book{aho:2007,  170 + author = {Aho, Alfred V. and Lam, Monica S. and Sethi, Ravi  171 + and Ullman, Jeffrey D.},  172 + ALTeditor = {},  173 + title = {{C}ompilers: {P}rinciples, {T}echniques \& {T}ools},  174 + publisher = {Pearson/Addison Wesley},  175 + year = {2007},  176 + OPTkey = {},  177 + OPTvolume = {},  178 + OPTnumber = {},  179 + OPTseries = {},  180 + OPTaddress = {},  181 + edition = {2nd},  182 + OPTmonth = {},  183 + OPTnote = {},  184 + OPTannote = {}  185 +}  186 +  187 +@Article{johnston:2004,  188 + author = {Johnston, Wesley M. and Hanna, J. R. Paul and Millar,  189 + Richard J.},  190 + title = {{A}dvances in {D}ataflow {P}rogramming {L}anguages},  191 + journal = {{ACM} Computing Surveys},  192 + year = {2004},  193 + OPTkey = {},  194 + volume = {36},  195 + number = {1},  196 + pages = {1--34},  197 + month = {March},  198 + OPTnote = {},  199 + OPTannote = {}  200 +}  201 + 
7  thesis/Chapters/Implementation.tex
 @@ -30,7 +30,7 @@ \subsection{Python} 30 30  both implemenation, compilation and execution of code were tied to 31 31  UNIX environments. The reason behind the consideration of the other 32 32  languages was that they are all supported by the \emph{BNF Converter} 33 -(BNFC). \citep{bnfc:online} BNFC is a compiler construction for 33 +(BNFC) \citep{bnfc:online}. BNFC is a compiler construction for 34 34  generating a compiler front-end from a Labeled BNF grammar. Given this 35 35  grammar, the tool produces 36 36  \begin{inparaenum}[(1)] @@ -39,8 +39,8 @@ \subsection{Python} 39 39  \item a lexer generator file; 40 40  \item a parser generator file; 41 41  \item a pretty-printer module; 42 -\item a \LaTeX file containing a specification of the language. 43 -\end{inparaenum} \citep{bnfc:online} 42 +\item a \LaTeX file containing a specification of the language 43 +\end{inparaenum} \citep{bnfc:online}. 44 44  While a compiler generator certainly would have made the 45 45  implementation alot easier, the Copernicus system is written in 46 46  python, and python does not exist as a target for the BNF Converter. @@ -80,6 +80,7 @@ \section{Implementation details} 80 80  \subsection{Abstract Syntax Tree}\label{sec:ast} 81 81  \input{Chapters/SectionsImplementation/ast} 82 82   83 + 83 84  \subsection{Codspeech BNF}\label{sec:bnf} 84 85  \input{Chapters/SectionsImplementation/bnf} 85 86 
46  thesis/Chapters/Research.tex
 ... ... @@ -1,7 +1,8 @@ 1 1  \chapter{Research}\label{chap:research} 2 -This chapter will give a brief exaplanation on how the project was 3 -executed, what stages . 4 - 2 +This chapter presents some of the research that was done on 3 +\emph{Copernicus}, different programming paradigms suitable for the 4 +problem domain, and existing programming languages appurtenant to 5 +those paradigms. 5 6   6 7  %\section{Project overview} 7 8  %The project contained three main stages: research, design and @@ -11,26 +12,43 @@ \chapter{Research}\label{chap:research} 11 12  %implementation and design stages continued through the entire project. 12 13   13 14   15 +\section{Requirements \& Specification} 16 + 17 + 14 18  \section{Programming Paradigms} 15 -We researched programming paradigms and programming languages similar 16 -to what we wanted to build. 19 +Different problem domains call for different programming 20 +paradigms. The execution model of \emph{Copernicus} can be though of 21 +as a flow network, which makes some paradigms more interesting, and 22 +the domain-specific language should be made to reflect that fact. 23 + 17 24   18 25  \subsection{Dataflow Programming} 19 -Dataflow programming is a paradigm that models programs as a directed 20 -graph of the data flowing between operations. It focuses on how 21 -components of the program \emph{connects} instead of, as in imperative 22 -programming, \emph{how they happen}. \highlight{Expand on this.} 26 +Dataflow programming is a paradigm which has an execution model where 27 +a program is represented as directed graph. The data flows between 28 +operations along the arcs. Directed arcs represent dependencies 29 +between instructions. Arcs that flow toward a node are called 30 +\emph{inputs}, while arcs flowing away from a node are called 31 +\emph{outputs} \citep{johnston:2004}. The model focuses on how 32 +components of the program \emph{connects} in contrast to the classical 33 +von Neuman model, which focuses on \emph{how they happen}. 34 + 23 35   24 36  \subsection{Flow-based Programming} 25 -In flow-based programming, applications are defined as networks of 26 -black box'' processes. Data is exchanged across predefined 27 -connections via message passing. \highlight{Expand on this.} 37 +In flow-based programming (FBP), applications are defined as networks 38 +of black box'' processes. Data is exchanged across predefined 39 +connections via message passing. The black box processes can be 40 +reconnected in different ways to form new applications while their 41 +internals remain unchanged, thus making FBP a 42 +\emph{component-oriented} approach. 43 + 28 44   29 45  \subsection{Reactive Programming} 30 -Oriented around data flows and the propagation of change. THe 46 +Oriented around data flows and the propagation of change. The 31 47  underlying execution model will automatically propagate changes 32 48  through the data flow. \highlight{Expand on this.} 33 49   34 50   35 -\section{Requirements \& Specification} 51 +\section{Programming Languages} 52 + 53 + 36 54 
25  thesis/Chapters/SectionsImplementation/ply.tex
 ... ... @@ -1,13 +1,14 @@ 1 -PLY is an implementation of lex and yacc parsing tools, written purely 2 -in python, by David Beazley \citep{ply:online}. It was originally 3 -developed for an intrdoctory class on compilers back in 2001. It 4 -provides most of the standard lex/yacc features including support for 5 -empty productions, precedence rules, error recovery, and support for 6 -ambigous grammars. It uses LR-parsing, which is a reasonabe parsing 7 -scheme for larger grammars, but slightly restrics the type of grammars 8 -that can be written (\highlight{citation needed}). PLY is 9 -straightforward to use, and one its many advantages is the \emph{very} 10 -extensive error checking, which certainly makes life easier. 1 +PLY is an implementation of \texttt{lex} and \texttt{yacc} parsing 2 +tools, written purely in python, by \citet{ply:online}. It was 3 +originally developed for an introductory class on compilers back in 4 +2001. It provides most of the standard lex/yacc features including 5 +support for empty productions, precedence rules, error recovery, and 6 +support for ambigous grammars. It uses LR-parsing, which is a 7 +reasonabe parsing scheme for larger grammars, but slightly restricts 8 +the type of grammars that can be written \citep{aho:2007}. PLY is 9 +straight-forward to use, and one its many advantages is 10 +the \emph{very} extensive error checking, which certainly makes life 11 +easier. 11 12   12 13  \paragraph{Python Lex} 13 14  The first step to implement the language is to write a tokenizer. This @@ -279,7 +280,7 @@ 279 280   280 281  Each function has a doc string that contains the appropriate 281 282  context-free grammar specification. This idea was actually borrowed 282 -from the SPARK toolkit. \citep{spark:online}. A function takes an 283 +from the SPARK toolkit \citep{spark:online}. A function takes an 283 284  argument, \emph{p}, that contains a sequence, starting at index 1, of 284 285  values matching the symbols in the corresponding rule. The value 285 286  \texttt{p[0]} is mapped to the left-hand-side rule, while the values @@ -294,4 +295,4 @@ 294 295  As seen in the above examples, both the lexer and parser are defined 295 296  from instances of their own classes. The easiest way, however, is to 296 297  specify them directly in their own modules. The PLY documentation 297 -explains this quite well, complete with examples. \citep{ply:online} 298 +explains this quite well, complete with examples \citep{ply:online}.
8  thesis/Codspeech.tex
 @@ -162,13 +162,7 @@ \part{Appendix} 162 162  \cleardoublepage\include{FrontBackmatter/Colophon} 163 163  \cleardoublepage\include{FrontBackmatter/Declaration} 164 164   165 -\nocite{chervenak:2001} 166 -\nocite{pronk:2011} 167 -\nocite{morrison:online} 168 -\nocite{morrison:2010} 169 -\nocite{pycparser:online} 170 -\nocite{ply:online} 171 -\nocite{bnfc:online} 165 +\nocite{*} 172 166   173 167  % ****************************************************************** 174 168  % Game Over: Restore, Restart, or Quit?
2  thesis/classicthesis-config.tex
2  thesis/classicthesis.sty

### No commit comments for this range

Something went wrong with that request. Please try again.