1. David Barker
  2. C# Arrows

Commits

David Barker  committed 7941c30

Tweaks to the dissertation

  • Participants
  • Parent commits 3ffeb4c
  • Branches master

Comments (0)

Files changed (8)

File Dissertation/Bibliography.bib

View file
  • Ignore whitespace
 
 @INPROCEEDINGS{invertible_arrows,
     author = {{Artem Alimarine and Sjaak Smetsers and Arjen Weelden and Marko Eekelen and Rinus Plasmeijer}},
-    title = {There and back again: arrows for invertible programming},
+    title = {There and Back Again: Arrows for Invertible Programming},
     booktitle = {In Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
     year = {2006},
     pages = {86--97},
 	title = {{Aspect Oriented Programming Using C$\sharp$ and PostSharp}},
 	author = {Reza Ahmadi},
 	note = {http://www.codeproject.com/Articles/337564/Aspect-Oriented-Programming-Using-Csharp-and-PostS}
+}
+
+@misc{haskell_wiki_arrows,
+	title = {Control.Arrow},
+	author = {Haskell Wiki},
+	note = {http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html}
 }

File Dissertation/Dissertation.aux

View file
  • Ignore whitespace
 \newlabel{fig:operator_correspondence}{{3.5}{13}}
 \@writefile{toc}{\contentsline {subsubsection}{Challenges encountered}{13}}
 \newlabel{sec:simple_arrow_challenges}{{3.2.2}{13}}
+\citation{invertible_arrows}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2.3}Invertible arrows}{14}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2.4}List arrows}{15}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2.5}Further utility arrows}{16}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.3.4}Integration work with WPF}{25}}
 \@writefile{lof}{\contentsline {figure}{\numberline {3.8}{\ignorespaces WPF integration demo}}{26}}
 \newlabel{fig:wpf_integration_demo}{{3.8}{26}}
+\citation{haskell_wiki_arrows}
 \@writefile{toc}{\contentsline {chapter}{\numberline {4}Evaluation}{27}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
 \bibcite{arrows_and_computation}{17}
 \bibcite{fogbugz}{18}
 \bibcite{frp_first_principles}{19}
-\bibcite{monads}{20}
+\bibcite{haskell_wiki_arrows}{20}
+\bibcite{monads}{21}
 \@writefile{toc}{\contentsline {chapter}{\numberline {A}Arrow laws}{47}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}

File Dissertation/Dissertation.bbl

View file
  • Ignore whitespace
 \bibitem{invertible_arrows}
 {Artem Alimarine and Sjaak Smetsers and Arjen Weelden and Marko Eekelen and
   Rinus Plasmeijer}.
-\newblock There and back again: arrows for invertible programming.
+\newblock There and back again: Arrows for invertible programming.
 \newblock In {\em In Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
   pages 86--97. ACM Press, 2006.
 
 \newblock In {\em In ACM SIGPLAN Conference on Programming Language Design and
   Implementation}, pages 242--252, 2000.
 
+\bibitem{haskell_wiki_arrows}
+Haskell Wiki.
+\newblock Control.arrow.
+\newblock
+  http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html.
+
 \bibitem{monads}
 Haskell Wiki.
 \newblock {Monads as Computation}.

File Dissertation/Dissertation.blg

View file
  • Ignore whitespace
 This is BibTeX, Version 0.99dThe top-level auxiliary file: Dissertation.aux
 The style file: plain.bst
-Illegal, another \bibstyle command---line 154 of file Dissertation.aux
+Illegal, another \bibstyle command---line 133 of file Dissertation.aux
  : \bibstyle
  :          {plain}
 I'm skipping whatever remains of this command
 Database file #1: Bibliography.bib
+Warning--I didn't find a database entry for "javabinding"
+Warning--I didn't find a database entry for "netbinding"
+Warning--I didn't find a database entry for "elliott98"
+Warning--I didn't find a database entry for "haskellarrows"
+Warning--I didn't find a database entry for "paterson03"
+Warning--I didn't find a database entry for "notifypropertychanged"
+Warning--I didn't find a database entry for "hughes98"
+Warning--I didn't find a database entry for "lindley08"
 Warning--empty journal in hughes_arrows
 Warning--empty journal in arrow_calculus
 (There was 1 error message)

File Dissertation/Dissertation.log

View file
  • Ignore whitespace
-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  1 MAY 2013 13:57
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  1 MAY 2013 16:48
 entering extended mode
 **Dissertation.tex
 
 Missing character: There is no � in font cmr12!
 Missing character: There is no � in font cmr12!
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <5> on input line 143.
-Missing character: There is no � in font cmr12!
-Missing character: There is no � in font cmr12!
-Missing character: There is no � in font cmr12!
+(Font)              <5> on input line 146.
  [2] [3] [4
 
 ]
 [9
 
 
-]
-LaTeX Font Info:    Font shape `OT1/cmtt/bx/n' in size <12> not available
-(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 233.
- <fig/ArrOperator.pdf, id=71, 259.19409pt x 106.89937pt>
+] <fig/ArrOperator.pdf, id=71, 259.19409pt x 106.89937pt>
 File: fig/ArrOperator.pdf Graphic file (type pdf)
 
 <use fig/ArrOperator.pdf>
-Package pdftex.def Info: fig/ArrOperator.pdf used on input line 238.
+Package pdftex.def Info: fig/ArrOperator.pdf used on input line 241.
 (pdftex.def)             Requested size: 142.26378pt x 58.67412pt.
 
 <fig/CompositionOperator.pdf, id=72, 349.81836pt x 107.12521pt>
 File: fig/CompositionOperator.pdf Graphic file (type pdf)
 
 <use fig/CompositionOperator.pdf>
-Package pdftex.def Info: fig/CompositionOperator.pdf used on input line 251.
+Package pdftex.def Info: fig/CompositionOperator.pdf used on input line 254.
 (pdftex.def)             Requested size: 142.26378pt x 43.56526pt.
  [10]
-<fig/FirstOperator.pdf, id=76, 262.49013pt x 219.44516pt>
+LaTeX Font Info:    Font shape `OT1/cmtt/bx/n' in size <12> not available
+(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 262.
+
+<fig/FirstOperator.pdf, id=77, 262.49013pt x 219.44516pt>
 File: fig/FirstOperator.pdf Graphic file (type pdf)
 
 <use fig/FirstOperator.pdf>
-Package pdftex.def Info: fig/FirstOperator.pdf used on input line 270.
+Package pdftex.def Info: fig/FirstOperator.pdf used on input line 273.
 (pdftex.def)             Requested size: 142.26378pt x 118.93391pt.
  [11 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/ArrOperator.pdf> <C:/Users/David/Documents/Visual Studio 2010/Pro
 File: fig/AndOperator.pdf Graphic file (type pdf)
 
 <use fig/AndOperator.pdf>
-Package pdftex.def Info: fig/AndOperator.pdf used on input line 285.
+Package pdftex.def Info: fig/AndOperator.pdf used on input line 288.
 (pdftex.def)             Requested size: 142.26378pt x 62.50134pt.
  [12 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/AndOperator.pdf>] [13] [14] [15]
 File: fig/BindingFramework.pdf Graphic file (type pdf)
 
 <use fig/BindingFramework.pdf>
-Package pdftex.def Info: fig/BindingFramework.pdf used on input line 423.
+Package pdftex.def Info: fig/BindingFramework.pdf used on input line 426.
 (pdftex.def)             Requested size: 411.93877pt x 189.23434pt.
  [17] [18 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBindin
 g/Dissertation/fig/BindingFramework.pdf>]
 [19] [20]
-LaTeX Font Info:    Try loading font information for OMS+cmr on input line 488.
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 491.
 
  ("C:\Program Files\MiKTeX 2.9\tex\latex\base\omscmr.fd"
 File: omscmr.fd 1999/05/25 v2.5h Standard LaTeX font definitions
 )
 LaTeX Font Info:    Font shape `OMS/cmr/m/n' in size <12> not available
-(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 488.
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 491.
  [21]
 [22] <fig/ArgumentMarshalling.pdf, id=178, 511.24123pt x 147.77261pt>
 File: fig/ArgumentMarshalling.pdf Graphic file (type pdf)
 
 <use fig/ArgumentMarshalling.pdf>
-Package pdftex.def Info: fig/ArgumentMarshalling.pdf used on input line 520.
+Package pdftex.def Info: fig/ArgumentMarshalling.pdf used on input line 523.
 (pdftex.def)             Requested size: 411.93877pt x 119.07281pt.
  [23 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/ArgumentMarshalling.pdf>]
 File: fig/WPFIntegrationDemo.png Graphic file (type png)
 
 <use fig/WPFIntegrationDemo.png>
-Package pdftex.def Info: fig/WPFIntegrationDemo.png used on input line 555.
+Package pdftex.def Info: fig/WPFIntegrationDemo.png used on input line 558.
 (pdftex.def)             Requested size: 411.93877pt x 146.96603pt.
  [25] [26 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBindin
 g/Dissertation/fig/WPFIntegrationDemo.png>]
 File: fig/CaseStudyNameBinding.png Graphic file (type png)
 
 <use fig/CaseStudyNameBinding.png>
-Package pdftex.def Info: fig/CaseStudyNameBinding.png used on input line 680.
+Package pdftex.def Info: fig/CaseStudyNameBinding.png used on input line 683.
 (pdftex.def)             Requested size: 283.0568pt x 210.78699pt.
  [32 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/CaseStudyNameBinding.png>]
 File: fig/CaseStudyListBinding.png Graphic file (type png)
 
 <use fig/CaseStudyListBinding.png>
-Package pdftex.def Info: fig/CaseStudyListBinding.png used on input line 701.
+Package pdftex.def Info: fig/CaseStudyListBinding.png used on input line 704.
 (pdftex.def)             Requested size: 411.93877pt x 292.66003pt.
  [33] [34 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBindin
 g/Dissertation/fig/CaseStudyListBinding.png>] [35]
 
 LaTeX Warning: Reference `sec:performance_enhancements' on page 36 undefined on
- input line 754.
+ input line 757.
 
 <fig/SimpleFunctionPerformanceChart.pdf, id=233, 496.44887pt x 258.75552pt>
 File: fig/SimpleFunctionPerformanceChart.pdf Graphic file (type pdf)
 
 <use fig/SimpleFunctionPerformanceChart.pdf>
 Package pdftex.def Info: fig/SimpleFunctionPerformanceChart.pdf used on input l
-ine 758.
+ine 761.
 (pdftex.def)             Requested size: 411.93877pt x 214.71175pt.
  [36]
 <fig/ListFunctionPerformanceChart.pdf, id=237, 496.4172pt x 244.72725pt>
 
 <use fig/ListFunctionPerformanceChart.pdf>
 Package pdftex.def Info: fig/ListFunctionPerformanceChart.pdf used on input lin
-e 777.
+e 780.
 (pdftex.def)             Requested size: 411.93877pt x 203.08247pt.
  [37 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/SimpleFunctionPerformanceChart.pdf>] <fig/IdentityChains.pdf, id=
 File: fig/IdentityChains.pdf Graphic file (type pdf)
 
 <use fig/IdentityChains.pdf>
-Package pdftex.def Info: fig/IdentityChains.pdf used on input line 791.
+Package pdftex.def Info: fig/IdentityChains.pdf used on input line 794.
 (pdftex.def)             Requested size: 411.93877pt x 179.69122pt.
  [38 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/ListFunctionPerformanceChart.pdf>]
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 117--121
+Overfull \hbox (119.76082pt too wide) in paragraph at lines 117--121
+[]\OT1/cmr/m/n/12 Haskell Wiki.  Con-trol.arrow.  http://www.haskell.org/ghc/do
+cs/latest/html/libraries/base/Control-
+ []
+
+
+Underfull \hbox (badness 10000) in paragraph at lines 123--127
 []\OT1/cmr/m/n/12 Haskell Wiki.  Mon-ads as Com-pu-ta-tion.
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 117--121
+Underfull \hbox (badness 10000) in paragraph at lines 123--127
 \OT1/cmr/m/n/12 http://www.haskell.org/haskellwiki/Monads[]as[]computation (ac-
 cessed
  []
 ]
 Appendix B.
 LaTeX Font Info:    Font shape `OT1/cmtt/bx/n' in size <8> not available
-(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 974.
+(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 977.
 [51
 
 ] [52
 \pc@column@2=\box30
 \pc@column@width@2=\dimen120
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1018.
+ne 1021.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1018.
+ne 1021.
 [53
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1073.
+ne 1076.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1073.
+ne 1076.
  [54]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1118.
+ne 1121.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1118.
+ne 1121.
  [55] [56]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1160.
+ne 1163.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1160.
+ne 1163.
  [57
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1202.
+ne 1205.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1202.
+ne 1205.
  [58]
 Appendix D.
 
 
  ) 
 Here is how much of TeX's memory you used:
- 3004 strings out of 494045
- 44385 string characters out of 3148387
+ 3005 strings out of 494045
+ 44406 string characters out of 3148387
  245619 words of memory out of 3000000
- 6270 multiletter control sequences out of 15000+200000
+ 6271 multiletter control sequences out of 15000+200000
  13106 words of font info for 47 fonts, out of 3000000 for 9000
  715 hyphenation exceptions out of 8191
  27i,8n,40p,1429b,1506s stack positions out of 5000i,500n,10000p,200000b,50000s
 TeX 2.9/fonts/type1/public/amsfonts/cm/cmtt10.pfb><C:/Program Files/MiKTeX 2.9/
 fonts/type1/public/amsfonts/cm/cmtt12.pfb><C:/Program Files/MiKTeX 2.9/fonts/ty
 pe1/public/amsfonts/cm/cmtt8.pfb>
-Output written on Dissertation.pdf (78 pages, 596173 bytes).
+Output written on Dissertation.pdf (78 pages, 597836 bytes).
 PDF statistics:
  667 PDF objects out of 1000 (max. 8388607)
  0 named destinations out of 1000 (max. 500000)

File Dissertation/Dissertation.pdf

  • Ignore whitespace
Binary file modified.

File Dissertation/Dissertation.synctex.gz

  • Ignore whitespace
Binary file modified.

File Dissertation/Dissertation.tex

View file
  • Ignore whitespace
 
 \section*{Work Completed}
 
-All the original goals were met: a general-purpose data binding framework based on arrows has been implemented, and an extensive arrow implementation has been completed. As well as the standard operators, a series of more complex extra operators have also been added, and some additional arrow types have been included -- for instance, 'list arrows' which map between enumerable data types. The framework allows bindings in both directions, between multiple sources and multiple destinations, and the arrows can be used in conjunction with WPF data binding with reasonable ease.
+All the original goals were met: a general-purpose data binding framework based on arrows has been implemented, and an extensive arrow implementation has been completed. As well as the standard operators, a series of more complex extra operators have also been added, and some additional arrow types have been included -- for instance, `list arrows' which map between enumerable data types. The framework allows bindings in both directions, between multiple sources and multiple destinations, and the arrows can be used in conjunction with WPF data binding with reasonable ease.
 
 %TODO
 %Continue this?
 material that has already been used to any substantial extent for a
 comparable purpose.
 
+I give permission for my dissertation to be made available in the archive
+area of the Laboratory's website.
+
 \bigskip
 \leftline{Signed}
 
 
 Data binding presents a mechanism for bridging the gap between the separated layers by allowing the developer to specify that some value in the user interface code should be bound to a property of the model. This usually simply means that whenever the value in the model changes, the data binding framework will ensure that the value in the user interface is also updated to the same value. However, bindings can often be more complex: for instance, there could be a text box in the user interface which reflects backend data but can also be used to change it (two-way binding). Alternatively, there might be a user interface component whose value is determined by some function of a variable in the model - consider a list view which displays a filtered and sorted version of a list stored in the model. There could even be values which depend on multiple sources, or more complex many-to-many bindings.
 
-Many current languages and frameworks provide data binding features with varying levels of complexity. Java has a variety of extension libraries [examples] which allow the programmer to use data binding with Swing. Javascript too has a variety of possibilities, with a prominent example being the backbone.js MVC framework. Unfortunately, many of these are quite limited and difficult to use - backbone.js, for example, only provides one-way binding and requires a lot of boilerplate code from the programmer.
+Many current languages and frameworks provide data binding features with varying levels of complexity. Java has a variety of extension libraries which allow the programmer to use data binding with Swing. Javascript too offers a number of possibilities, with a prominent example being the backbone.js MVC framework. Unfortunately, many of these are quite limited and difficult to use - backbone.js, for example, only provides one-way binding and requires a lot of boilerplate code from the programmer.
 
 \section{Data binding in .NET}
 
-Microsoft’s .NET framework offers a particularly powerful example of data binding through Windows Presentation Foundation (WPF). Based on the MVVM architecture, it has many features to allow things like two-way binding, binding through functions and bindings based on list operations. One of its key advantages is that the user interface can be defined entirely in XAML \footnote{Extensible Application Markup Language, an XML-based markup language for defining user interfaces and simple behaviour} with bindings being specified through XAML parameters. The view logic is then specified in the ViewModel which in turn communicates with the model. This means user interface designers can work purely in XAML without concern for the logic or binding mechanisms in place behind the scenes.
+Microsoft’s .NET framework offers a particularly powerful example of data binding through Windows Presentation Foundation (WPF). Based on the MVVM architecture, it has many features to allow things like two-way binding, binding through functions and bindings based on list operations. One of its key advantages is that the user interface can be defined entirely in XAML\footnote{Extensible Application Markup Language, an XML-based markup language for defining user interfaces and simple behaviour} with bindings being specified through XAML parameters. The view logic is then specified in the ViewModel which in turn communicates with the model. This means user interface designers can work purely in XAML without concern for the logic or binding mechanisms in place behind the scenes.
 
-However, WPF suffers from a similar problem to many other data binding frameworks: advanced data bindings can be very complex and difficult to manage, and setting up bindings in the first place requires quite a lot of boilerplate code in the model and view. Furthermore, binding through functions requires special `value converter’ classes to be written. This is essentially an application of the Template pattern, and the value converters are not type safe - they take objects as input and return objects as output (and bindings with multiple inputs will simply take arrays of objects with no guarantee that the right number of values has been passed). Clearly a more simple and general binding framework would definitely make application development simpler.
+However, WPF suffers from a similar problem to many other data binding frameworks: advanced data bindings can be very complex and difficult to manage, and setting up bindings in the first place requires quite a lot of boilerplate code in the model and view. Furthermore, binding through functions requires special `value converter' classes to be written. This is essentially an application of the Template pattern, and the value converters are not type safe - they take objects as input and return objects as output (and bindings with multiple inputs will simply take arrays of objects with no guarantee that the right number of values has been passed). Clearly a more simple and general binding framework would definitely make application development simpler.
 %TODO Maybe more disadvantages?
 
 \section{Project inspirations}
 
 The first objective in implementing arrows was to get the simple function-based arrow working, as all the others derive from this. As mentioned earlier, it was implemented using the C$\sharp$ \texttt{Func<A, B>} class to hold its function. An \texttt{Invoke} method is then exposed for using the arrow.
 
-Whilst arrows can be constructed using \texttt{new Arrow<A, B>(function)}, a simpler syntax is provided by an extension method:
+Whilst arrows can be constructed using \texttt{new Arrow<A, B>(function)}\footnote{\texttt{function} is a \texttt{Func<A, B>} here}, a simpler syntax is provided by an extension method:
 
 \begin{lstlisting}[language={[Sharp]C}]
-var increment = ((int x) => x + 1).Arr();
+var increment = function.Arr();
 \end{lstlisting}
 
 \begin{figure}[!ht]
   \label{fig:first_operator}
 \end{figure}
 
-The above syntax may not immediately make sense. Essentially, the \texttt{default(T)} passes in null if \texttt{T} is a reference type and some sensible default if it is a null type. The only purpose for this parameter is to allow the compiler to infer the type of the second argument to the resulting arrow, and so any value of the appropriate type would work -- \texttt{default(T)} is used for simplicity. This is the one syntax `glitch' which I was unable to remove, and is explained in more detail at the end of this subsection.
+The above syntax may not immediately make sense. Essentially, the \texttt{default(T)} passes in null if \texttt{T} is a reference type and some sensible default if it is a value type. The only purpose for this parameter is to allow the compiler to infer the type of the second argument to the resulting arrow, and so any value of the appropriate type would work -- \texttt{default(T)} is used for simplicity. This is the one syntax `glitch' which I was unable to remove, and is explained in more detail at the end of this subsection.
 
 Going beyond the basic operators, many composite operators were also implemented based on these simple combinators. For instance, \texttt{Second} was implemented in terms of \texttt{First}. The standard parallel combinator was also implemented as \texttt{And}:
 
 
 At the time of writing the proposal, I was still unsure of the best way of implementing invertible arrows. There were two main strategies I was considering: simply requiring the user to supply an arrow for each direction, or providing a basic set of invertible functions and allowing the user to compose these together to build up more complex functions. The former wouldn't have worked very well as part of the advantage of using arrows in data binding is that simple ones can be re-used in building up multiple different bindings, and having to build up two arrows independently would be very messy and prone to error. The latter also has several problems. For instance, what functions should be made available to prevent the system being too restrictive? Also, if the functions were too simple then many would need to be combined in most cases, and this can cause a lot of unnecessary overhead (as explored in Section~\ref{sec:arrow_chaining_overhead}).
 
-Ultimately, a solution roughly combining the two approaches was found. This was largely inspired by [REF], and is based on an \texttt{Arr} operator which takes \textit{two} functions rather than one -- one function for each direction. The arrows can then be combined using all the same combinators as are available for simple arrows (bar those which don't have inverses, such as \texttt{Unsplit}). As a result, it gives the same flexibility as allowing the user to simply define two arrows, but saves time by retaining the composability that makes arrows useful. An example of how an invertible arrow can be constructed using the \texttt{Arr} extension method is given below:
+Ultimately, a solution roughly combining the two approaches was found. This was largely inspired by \cite{invertible_arrows}, and is based on an \texttt{Arr} operator which takes \textit{two} functions rather than one -- one function for each direction. The arrows can then be combined using all the same combinators as are available for simple arrows (bar those which don't have inverses, such as \texttt{Unsplit}). As a result, it gives the same flexibility as allowing the user to simply define two arrows, but saves time by retaining the composability that makes arrows useful. An example of how an invertible arrow can be constructed using the \texttt{Arr} extension method is given below:
 
 \begin{lstlisting}[language={[Sharp]C}]
 var invertibleIncrement = new Func((int x) => x + 1)
 
 \subsection{List arrows}
 
-Whilst exploring existing uses of data binding in WPF applications, it was discovered that a fairly common use case involves binding some form of list display to an enumerable data structure in the model. WPF provides support for this already, but trying to do it with arrows would be syntactically clunky -- for one thing, the arrow types would all be of the form \texttt{Arrow<IEnumerable<T1>, IEnumerable<T2>>}. To simplify this I decided it would make sense to implement an 'arrow on lists' abstracting away the actual list processing details and exposing a simple set of common list operators.
+Whilst exploring existing uses of data binding in WPF applications, it was discovered that a fairly common use case involves binding some form of list display to an enumerable data structure in the model. WPF provides support for this already, but trying to do it with arrows would be syntactically clunky -- for one thing, the arrow types would all be of the form \texttt{Arrow<IEnumerable<T1>, IEnumerable<T2>>}. To simplify this I decided it would make sense to implement an `arrow on lists' abstracting away the actual list processing details and exposing a simple set of common list operators.
 
 The result is a set of simple arrows implementing SQL-like functionality on enumerable data sources. List arrows are all of the type \texttt{ListArrow<T1, T2>}, which extends \texttt{Arrow<IEnumerable<T1>, IEnumerable<T2>>} for compatibility with existing arrows. There are a variety of simple list arrows which can be combined to build up complex functionality:
 
 
 \subsection{Overall architecture}
 
-The basis for the data binding system is a publish/subscribe network, where bound values publish events when they are updated and bindings update on receiving these events. A couple of alternatives were considered for this: the first idea was to have binding sources hold a reference to their target and a copy of the arrow associated with the binding, allowing them to simply update the referenced value via the arrow when needed. However, C$\sharp$ lacks the ability to hold references as member variables in this way. The simple approach of simply periodically polling all bound variables to check for updates was also considered, but this was clearly no good: polling is system-intensive and wasteful with many bindings using the same source, a binding target's value would potentially be 'invalid' between polling updates, and the bindings manager would need to store a copy of every bound variable.
+The basis for the data binding system is a publish/subscribe network, where bound values publish events when they are updated and bindings update on receiving these events. A couple of alternatives were considered for this: the first idea was to have binding sources hold a reference to their target and a copy of the arrow associated with the binding, allowing them to simply update the referenced value via the arrow when needed. However, C$\sharp$ lacks the ability to hold references as member variables in this way. The simple approach of simply periodically polling all bound variables to check for updates was also considered, but this was clearly no good: polling is system-intensive and wasteful with many bindings using the same source, a binding target's value would potentially be `invalid' between polling updates, and the bindings manager would need to store a copy of every bound variable.
 
 Conveniently, C$\sharp$ provides simple syntax for event-based programming. Events can be created for a class and thrown with a method call, and other objects can subscribe and unsubscribe simply by adding or removing their handler methods from the event. The clearest approach was therefore to attach events to bindable objects and have them trigger whenever a bound variable is updated. The bindings manager, when creating a binding, need only tell the binding to subscribe to the source object's event and it will then be notified of all updates to variables. Information stored in the event arguments is used to filter out events from variables the binding is not watching, and the updated value is passed through the binding's arrow and then assigned to the destination variable. This approach is shown in Figure \ref{fig:binding_framework}.
 
 
 \subsubsection*{PostSharp}
 
-PostSharp is a C$\sharp$ extension which provides aspect-oriented programming (AOP) functionality. Essentially, AOP is a means of separating cross-cutting concerns from the code they affect, allowing 'aspects' to be written providing this common functionality. Markers can then be placed in the appropriate points, and the aspects will generate and inject their code into these locations at compile time.
+PostSharp is a C$\sharp$ extension which provides aspect-oriented programming (AOP) functionality. Essentially, AOP is a means of separating cross-cutting concerns from the code they affect, allowing `aspects' to be written providing this common functionality. Markers can then be placed in the appropriate points, and the aspects will generate and inject their code into these locations at compile time.
 
 In this case, the \texttt{Bindable} aspect will intercept the setter of any property or member variable it is placed above and insert code to check whether the value has changed and throw appropriate events if it has. This does not interfere with any setters the programmer may already have specified, as it defers to the programmer's setter before throwing the event for the value changing (thus ensuring the event is only thrown once all values are updated and any side-effects have occurred). The technique for doing this was inspired by~\cite{postsharp_propertychanged} and~\cite{postsharp_locationinterception}.
 
-Unfortunately, the project budget only extended as far as the free version of PostSharp. Syntax for bindings could likely have been improved even further using the method and property introduction features provided by the full version, as this would have removed the need to extend Bindable. The unfortunate side-effect of the Bindable base class is that the class can no longer extend any other base class, as C$\sharp$ does not allow multiple class inheritance. However, in working with the binding framework it was found that this rarely caused problems that couldn't be worked around, and in any case patterns exist to overcome the lack of multiple inheritance in the general case\footnote{The 'composition over inheritance' pattern is one such technique which uses a shared base interface and a proxy object to 'inherit' from a class without using actual inheritance}.
+Unfortunately, the project budget only extended as far as the free version of PostSharp. Syntax for bindings could likely have been improved even further using the method and property introduction features provided by the full version, as this would have removed the need to extend Bindable. The unfortunate side-effect of the Bindable base class is that the class can no longer extend any other base class, as C$\sharp$ does not allow multiple class inheritance. However, in working with the binding framework it was found that this rarely caused problems that couldn't be worked around, and in any case patterns exist to overcome the lack of multiple inheritance in the general case\footnote{The `composition over inheritance' pattern is one such technique which uses a shared base interface and a proxy object to `inherit' from a class without using actual inheritance}.
 
 \subsection{Creating bindings}
 
 
 \subsubsection{Syntax and usage}
 
-In order to abstract away details like types and specific object references, the bindings manager operates on 'bind points' -- essentially, structures containing a reference to the \texttt{Bindable} source and a string representation of the property or member variable being bound. An extension method was written to make creating these simpler, as calling the constructor with the object and variable name turned out to make the overall syntax fairly cluttered. The standard way of making a bind point for an object 'obj' with property 'value' is thus \texttt{obj.GetBindPoint("value")}, which is a lot simpler to write.
+In order to abstract away details like types and specific object references, the bindings manager operates on `bind points' -- essentially, structures containing a reference to the \texttt{Bindable} source and a string representation of the property or member variable being bound. An extension method was written to make creating these simpler, as calling the constructor with the object and variable name turned out to make the overall syntax fairly cluttered. The standard way of making a bind point for an object `obj' with property `value' is thus \texttt{obj.GetBindPoint("value")}, which is a lot simpler to write.
 
 Basic bindings (that is, from one source to one destination in one direction) can be set up by passing in a source bind point, and arrow to use for the binding and a destination bind point. An example of this is given in Listing~\ref{lst:creating_simple_binding}.
 
 
 function checkCycles(node, seen)
   if node in seen:
-    return 'cycle'
+    return `cycle'
   else:
     add node to seen
     for each child node:
       checkCycles(child, seen)
 \end{lstlisting}
 
-Further to detecting these situations, another issue which had to be resolved was what action to take on finding a problem. Were the programmer to create a new binding between two objects which were already bound, a possible response would be to simply overwrite the old binding. This would prevent errors from the framework disrupting the user, and is also a fairly reasonable behaviour to expect. However, it was decided that this made the binding process too opaque and could lead to confusing behaviour if the programmer had accidentally overwritten a binding -- for instance, by mistyping the name of one of the objects they intended to bind. Therefore, whenever the programmer attempts to create a binding which would lead to a cycle or conflict, the framework throws an exception explaining the error. The behaviour of 'overwriting' an old binding is still possible as the \texttt{BindingsManager} provides a method for removing specific bindings, but now the programmer has to do the overwriting explicitly.
+Further to detecting these situations, another issue which had to be resolved was what action to take on finding a problem. Were the programmer to create a new binding between two objects which were already bound, a possible response would be to simply overwrite the old binding. This would prevent errors from the framework disrupting the user, and is also a fairly reasonable behaviour to expect. However, it was decided that this made the binding process too opaque and could lead to confusing behaviour if the programmer had accidentally overwritten a binding -- for instance, by mistyping the name of one of the objects they intended to bind. Therefore, whenever the programmer attempts to create a binding which would lead to a cycle or conflict, the framework throws an exception explaining the error. The behaviour of `overwriting' an old binding is still possible as the \texttt{BindingsManager} provides a method for removing specific bindings, but now the programmer has to do the overwriting explicitly.
 
 \subsubsection{Many-to-many bindings} \label{sec:many_many_bindings}
 
   \label{fig:argument_marshalling}
 \end{figure}
 
-By using reflection on the type of the arrow, I was able to convert a list of bind points to a binary-tree-structured Tuple. The code essentially does a recursive depth-first search through the input type of the arrow (obtained via reflection), simultaneously constructing a Tuple of the same structure and inserting values from the bind points wherever a 'leaf' is encountered in the type being searched. At the other end, a similar process is used to extract the values from the returned tuple and put them into a list which is then used to assign to the destination bind points. The process is illustrated in Figure~\ref{fig:argument_marshalling}, where a set of inputs of types A, B and C are being passed into an arrow from type \texttt{Tuple<Tuple<A, B>, C>} to type \texttt{Tuple<A, Tuple<B, C>>}.
+By using reflection on the type of the arrow, I was able to convert a list of bind points to a binary-tree-structured Tuple. The code essentially does a recursive depth-first search through the input type of the arrow (obtained via reflection), simultaneously constructing a Tuple of the same structure and inserting values from the bind points wherever a `leaf' is encountered in the type being searched. At the other end, a similar process is used to extract the values from the returned tuple and put them into a list which is then used to assign to the destination bind points. The process is illustrated in Figure~\ref{fig:argument_marshalling}, where a set of inputs of types A, B and C are being passed into an arrow from type \texttt{Tuple<Tuple<A, B>, C>} to type \texttt{Tuple<A, Tuple<B, C>>}.
 
 \subsubsection{Problems encountered}
 
 
 \section{Correctness of arrow implementations}
 
-The key requirement for an arrow type satisfying the original definition by Hughes is that it conforms to a set of 'arrow laws' defining how the various basic combinators should work. While there are numerous variations on the set of arrow laws, the standard ones used by Haskell are given in [REF]. These are listed in Appendix \ref{sec:arrow_laws}, along with their equivalent definitions using the C$\sharp$ syntax.
+The key requirement for an arrow type satisfying the original definition by Hughes is that it conforms to a set of 'arrow laws' defining how the various basic combinators should work. While there are numerous variations on the set of arrow laws, the standard ones used by Haskell are given in~\cite{haskell_wiki_arrows}. These are listed in Appendix \ref{sec:arrow_laws}, along with their equivalent definitions using the C$\sharp$ syntax.
 
 As invertible arrows conform to a slightly different set of arrow laws (which put extra requirements on their inverses), both one-way arrows and invertible arrows had to be tested separately. List and choice arrows were not separately tested as they are entirely built upon normal one-way arrows, and so will conform to the arrow laws for free if simple arrows do.
 
 
 This differs from the other laws because it has to be proven true over all \textit{types} rather than simply for all inputs. As such, the test proceeds by obtaining a representative list of types and using reflection to build an identity arrow for each, then uses the standard technique of firing lots or random inputs at it and asserting that the arrow does indeed represent the identity function. The set of types used was just the set of primitive types, obtained by querying the current assembly for all available types and filtering the non-primitive ones (as non-primitive types would have to be initialised to null, which defeats the purpose of testing correctness over all types).
 
-To reduce complexity, 'random' arrows were produced by randomly selecting a function from a set of pre-defined functions and constructing an arrow with it. It seems reasonable to assume that if an arrow law were to hold for some combination of these functions, but fail on another, then the problem is more likely with the C$\sharp$ compiler than with the arrow implementation.
+To reduce complexity, `random' arrows were produced by randomly selecting a function from a set of pre-defined functions and constructing an arrow with it. It seems reasonable to assume that if an arrow law were to hold for some combination of these functions, but fail on another, then the problem is more likely with the C$\sharp$ compiler than with the arrow implementation.
 
 \subsubsection{Invertible arrows}