Commits

David Barker  committed 7a77b89

Added more explanation to the simple arrows implementation section

  • Participants
  • Parent commits f01d727

Comments (0)

Files changed (11)

File Dissertation/Bibliography.bib

 @INPROCEEDINGS{frp_first_principles,
     author = {Zhanyong Wan and Paul Hudak},
     title = {{Functional Reactive Programming from First Principles}},
-    booktitle = {In ACM SIGPLAN Conference on Programming Language Design and Implementation},
+    booktitle = {ACM SIGPLAN Conference on Programming Language Design and Implementation},
     year = {2000},
     pages = {242--252}
 }
 url={http://dx.doi.org/10.1007/3-540-49099-X_1},
 publisher={Springer Berlin Heidelberg},
 author={Hudak, Paul},
-pages={1-1},
 language={English}
 }
 
 @INPROCEEDINGS{invertible_arrows,
-    author = {{Artem Alimarine and Sjaak Smetsers and Arjen Weelden and Marko Eekelen and Rinus Plasmeijer}},
+    author = {{Artem Alimarine, Sjaak Smetsers, Arjen Weelden, Marko Eekelen, and Rinus Plasmeijer}},
     title = {There and Back Again: Arrows for Invertible Programming},
-    booktitle = {In Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
+    booktitle = {Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
     year = {2006},
     pages = {86--97},
     publisher = {ACM Press}
 @misc{postsharp,
 	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}
+	note = {\url{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}
+	note = {\url{http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html}}
 }
 
 @misc{mvvm,
 	title = {{WPF Apps With The Model-View-ViewModel Design Pattern}},
 	author = {Josh Smith},
-	note = {\\http://msdn.microsoft.com/en-us/magazine/dd419663.aspx}
+	note = {\url{http://msdn.microsoft.com/en-us/magazine/dd419663.aspx}}
+}
+
+@misc{roslyn,
+	title = {{The Roslyn Project}},
+	author = {{MSDN}},
+	note = {\url{http://msdn.microsoft.com/en-us/vstudio/hh500769} (accessed on 09/05/2013)}
 }

File Dissertation/Dissertation.aux

 \@writefile{toc}{\contentsline {subsection}{\numberline {2.1.1}Functional reactive programming}{5}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {2.1.2}Arrows}{5}}
 \@writefile{toc}{\contentsline {section}{\numberline {2.2}Requirements analysis}{6}}
-\citation{fogbugz}
 \@writefile{toc}{\contentsline {section}{\numberline {2.3}Software engineering approach}{7}}
+\citation{fogbugz}
 \citation{bitbucket}
 \@writefile{toc}{\contentsline {chapter}{\numberline {3}Implementation}{9}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
 \@writefile{toc}{\contentsline {section}{\numberline {3.1}Overview}{9}}
 \@writefile{toc}{\contentsline {section}{\numberline {3.2}Arrows}{9}}
+\newlabel{sec:arrows}{{3.2}{9}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.2.1}Overview}{9}}
 \newlabel{sec:arrows_overview}{{3.2.1}{9}}
 \citation{extension_methods}
 \newlabel{sec:further_utility_arrows}{{3.2.5}{16}}
 \@writefile{toc}{\contentsline {section}{\numberline {3.3}Data binding}{17}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {3.3.1}Overall architecture}{17}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.3.2}Creating bindable sources and destinations}{17}}
 \@writefile{lof}{\contentsline {figure}{\numberline {3.6}{\ignorespaces Overview of the binding method}}{18}}
 \newlabel{fig:binding_framework}{{3.6}{18}}
-\newlabel{lst:bindable_source_class}{{3.1}{18}}
-\@writefile{lol}{\contentsline {lstlisting}{\numberline {3.1}Creating a bindable source class}{18}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3.2}Creating bindable sources and destinations}{18}}
 \citation{postsharp_propertychanged}
 \citation{postsharp_locationinterception}
-\@writefile{toc}{\contentsline {subsection}{\numberline {3.3.3}Creating bindings}{19}}
+\newlabel{lst:bindable_source_class}{{3.1}{19}}
+\@writefile{lol}{\contentsline {lstlisting}{\numberline {3.1}Creating a bindable source class}{19}}
+\@writefile{toc}{\contentsline {subsection}{\numberline {3.3.3}Creating bindings}{20}}
 \@writefile{toc}{\contentsline {subsubsection}{Syntax and usage}{20}}
 \newlabel{lst:creating_simple_binding}{{3.2}{20}}
 \@writefile{lol}{\contentsline {lstlisting}{\numberline {3.2}Creating a binding between two properties}{20}}
 \@writefile{lol}{\contentsline {lstlisting}{\numberline {3.3}Pseudocode for cycle and conflict detection}{22}}
 \@writefile{toc}{\contentsline {subsubsection}{Many-to-many bindings}{23}}
 \newlabel{sec:many_many_bindings}{{3.3.3}{23}}
-\@writefile{lof}{\contentsline {figure}{\numberline {3.7}{\ignorespaces Marshalling a list of BindPoint sources to pass to an arrow and unmarshalling the result}}{23}}
-\newlabel{fig:argument_marshalling}{{3.7}{23}}
+\@writefile{lof}{\contentsline {figure}{\numberline {3.7}{\ignorespaces Marshalling a list of BindPoint sources to pass to an arrow and unmarshalling the result}}{24}}
+\newlabel{fig:argument_marshalling}{{3.7}{24}}
 \@writefile{toc}{\contentsline {subsubsection}{Problems encountered}{24}}
 \@writefile{toc}{\contentsline {paragraph}{Type safety}{24}}
 \@writefile{toc}{\contentsline {paragraph}{Binding to lists}{24}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.2.1}Arrow syntax}{29}}
 \@writefile{toc}{\contentsline {subsubsection}{Comparison with Haskell}{30}}
 \newlabel{sec:syntax_comparison_haskell}{{4.2.1}{30}}
+\citation{roslyn}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.2.2}Binding syntax}{31}}
 \@writefile{toc}{\contentsline {subsubsection}{Username two-way binding}{32}}
 \@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces The username two-way binding application}}{32}}
 \bibcite{wpf_data_binding_overview}{12}
 \bibcite{extension_methods}{13}
 \bibcite{total_processor_time}{14}
-\bibcite{haskell_arrows}{15}
-\bibcite{arrow_notation}{16}
-\bibcite{arrows_and_computation}{17}
-\bibcite{mvvm}{18}
-\bibcite{fogbugz}{19}
-\bibcite{frp_first_principles}{20}
-\bibcite{haskell_wiki_arrows}{21}
-\bibcite{monads}{22}
+\bibcite{roslyn}{15}
+\bibcite{haskell_arrows}{16}
+\bibcite{arrow_notation}{17}
+\bibcite{arrows_and_computation}{18}
+\bibcite{mvvm}{19}
+\bibcite{fogbugz}{20}
+\bibcite{frp_first_principles}{21}
+\bibcite{haskell_wiki_arrows}{22}
+\bibcite{monads}{23}
 \@writefile{toc}{\contentsline {chapter}{\numberline {A}Arrow laws}{47}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}

File Dissertation/Dissertation.bbl

 Reza Ahmadi.
 \newblock {Aspect Oriented Programming Using C$\sharp$ and PostSharp}.
 \newblock
-  \\http://www.codeproject.com/Articles/337564/Aspect-Oriented-Programming-Using-Csharp-and-PostS.
+  \url{http://www.codeproject.com/Articles/337564/Aspect-Oriented-Programming-Using-Csharp-and-PostS}.
 
 \bibitem{invertible_arrows}
-{Artem Alimarine and Sjaak Smetsers and Arjen Weelden and Marko Eekelen and
-  Rinus Plasmeijer}.
+{Artem Alimarine, Sjaak Smetsers, Arjen Weelden, Marko Eekelen, and Rinus
+  Plasmeijer}.
 \newblock There and back again: Arrows for invertible programming.
-\newblock In {\em In Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
+\newblock In {\em Proceedings of the 2005 ACM SIGPLAN workshop on Haskell},
   pages 86--97. ACM Press, 2006.
 
 \bibitem{bitbucket}
 Paul Hudak.
 \newblock {Functional Reactive Programming}.
 \newblock In S.Doaitse Swierstra, editor, {\em Programming Languages and
-  Systems}, volume 1576 of {\em Lecture Notes in Computer Science}, pages 1--1.
-  Springer Berlin Heidelberg, 1999.
+  Systems}, volume 1576 of {\em Lecture Notes in Computer Science}. Springer
+  Berlin Heidelberg, 1999.
 
 \bibitem{arrows_robots_frp}
 Paul Hudak, Antony Courtney, Henrik Nilsson, and John Peterson.
   \url{http://msdn.microsoft.com/en-us/library/system.diagnostics.process.totalprocessortime.aspx}
   (accessed on 30/04/2013).
 
+\bibitem{roslyn}
+{MSDN}.
+\newblock {The Roslyn Project}.
+\newblock \url{http://msdn.microsoft.com/en-us/vstudio/hh500769} (accessed on
+  09/05/2013).
+
 \bibitem{haskell_arrows}
 Ross Paterson.
 \newblock {Arrows: A General Interface to Computation}.
 \bibitem{mvvm}
 Josh Smith.
 \newblock {WPF Apps With The Model-View-ViewModel Design Pattern}.
-\newblock \\http://msdn.microsoft.com/en-us/magazine/dd419663.aspx.
+\newblock \url{http://msdn.microsoft.com/en-us/magazine/dd419663.aspx}.
 
 \bibitem{fogbugz}
 FogCreek Software.
 \bibitem{frp_first_principles}
 Zhanyong Wan and Paul Hudak.
 \newblock {Functional Reactive Programming from First Principles}.
-\newblock In {\em In ACM SIGPLAN Conference on Programming Language Design and
+\newblock In {\em 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.
+  \url{http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html}.
 
 \bibitem{monads}
 Haskell Wiki.

File Dissertation/Dissertation.blg

 This is BibTeX, Version 0.99dThe top-level auxiliary file: Dissertation.aux
 The style file: plain.bst
-Illegal, another \bibstyle command---line 135 of file Dissertation.aux
+Illegal, another \bibstyle command---line 137 of file Dissertation.aux
  : \bibstyle
  :          {plain}
 I'm skipping whatever remains of this command

File Dissertation/Dissertation.lof

 \contentsline {figure}{\numberline {3.4}{\ignorespaces The And operator}}{12}
 \contentsline {figure}{\numberline {3.5}{\ignorespaces Correspondence between Haskell and C$\sharp $ arrow operators}}{13}
 \contentsline {figure}{\numberline {3.6}{\ignorespaces Overview of the binding method}}{18}
-\contentsline {figure}{\numberline {3.7}{\ignorespaces Marshalling a list of BindPoint sources to pass to an arrow and unmarshalling the result}}{23}
+\contentsline {figure}{\numberline {3.7}{\ignorespaces Marshalling a list of BindPoint sources to pass to an arrow and unmarshalling the result}}{24}
 \contentsline {figure}{\numberline {3.8}{\ignorespaces WPF integration demo}}{26}
 \addvspace {10\p@ }
 \contentsline {figure}{\numberline {4.1}{\ignorespaces The username two-way binding application}}{32}

File Dissertation/Dissertation.log

-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  8 MAY 2013 17:53
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  10 MAY 2013 11:56
 entering extended mode
 **Dissertation.tex
 
 <use fig/ArrOperator.pdf>
 Package pdftex.def Info: fig/ArrOperator.pdf used on input line 238.
 (pdftex.def)             Requested size: 142.26378pt x 58.67412pt.
-
-<fig/CompositionOperator.pdf, id=72, 349.81836pt x 107.12521pt>
+ [10]
+<fig/CompositionOperator.pdf, id=76, 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.
 (pdftex.def)             Requested size: 142.26378pt x 43.56526pt.
- [10]
 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 259.
 
 jects/ArrowDataBinding/Dissertation/fig/CompositionOperator.pdf> <C:/Users/Davi
 d/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dissertation/fig/First
 Operator.pdf>]
+Underfull \hbox (badness 1082) in paragraph at lines 283--284
+[]\OT1/cmr/m/n/12 This is com-monly thought of as com-bin-ing lef-t-Ar-row and 
+rightAr-row
+ []
+
 <fig/AndOperator.pdf, id=106, 565.02242pt x 248.2334pt>
 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 287.
 (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 425.
 (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 490.
 
  ("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 490.
  [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 522.
 (pdftex.def)             Requested size: 411.93877pt x 119.07281pt.
- [23 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
-sertation/fig/ArgumentMarshalling.pdf>]
-[24] <fig/WPFIntegrationDemo.png, id=195, 571.13374pt x 203.76125pt>
+ [23] [24 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBindin
+g/Dissertation/fig/ArgumentMarshalling.pdf>]
+<fig/WPFIntegrationDemo.png, id=195, 571.13374pt x 203.76125pt>
 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 557.
 (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 682.
 (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 703.
 (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]
 
 <use fig/SimpleFunctionPerformanceChart.pdf>
 Package pdftex.def Info: fig/SimpleFunctionPerformanceChart.pdf used on input l
-ine 758.
+ine 760.
 (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 779.
 (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 793.
 (pdftex.def)             Requested size: 411.93877pt x 179.69122pt.
  [38 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/ListFunctionPerformanceChart.pdf>]
 ("C:\Users\David\Documents\Visual Studio 2010\Projects\ArrowDataBinding\Dissert
 ation\Dissertation.bbl"
 Underfull \hbox (badness 10000) in paragraph at lines 4--8
-\OT1/cmr/m/n/12 http://www.codeproject.com/Articles/337564/Aspect-Oriented-
+$\OT1/cmtt/m/n/12 http : / / www . codeproject . com / Articles / 337564 / Aspe
+ct -[] Oriented -[]$
  []
 
 
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 123--127
-\OT1/cmr/m/n/12 http://www.haskell.org/ghc/docs/latest/html/libraries/base/Cont
-rol-
+Underfull \hbox (badness 1308) in paragraph at lines 90--94
+[]\OT1/cmr/m/n/12 MSDN.  The Roslyn Project.  $\OT1/cmtt/m/n/12 http : / / msdn
+ . microsoft . com / en -[] us /$
+ []
+
+
+Underfull \hbox (badness 1478) in paragraph at lines 129--133
+[]\OT1/cmr/m/n/12 Haskell Wiki.  Con-trol.Arrow.  $\OT1/cmtt/m/n/12 http : / / 
+www . haskell . org / ghc / docs /$
  []
 
 ) [46]
 ]
 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 976.
 [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 1020.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1018.
+ne 1020.
 [53
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1073.
+ne 1075.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1073.
+ne 1075.
  [54]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1118.
+ne 1120.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1118.
+ne 1120.
  [55] [56]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1160.
+ne 1162.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1160.
+ne 1162.
  [57
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1202.
+ne 1204.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1202.
+ne 1204.
  [58]
 Appendix D.
 
 
  ) 
 Here is how much of TeX's memory you used:
- 3079 strings out of 494045
- 45292 string characters out of 3148387
+ 3081 strings out of 494045
+ 45312 string characters out of 3148387
  245619 words of memory out of 3000000
- 6341 multiletter control sequences out of 15000+200000
+ 6343 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,1424b,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, 599313 bytes).
+Output written on Dissertation.pdf (78 pages, 600047 bytes).
 PDF statistics:
  667 PDF objects out of 1000 (max. 8388607)
  0 named destinations out of 1000 (max. 500000)

File Dissertation/Dissertation.pdf

Binary file modified.

File Dissertation/Dissertation.synctex.gz

Binary file modified.

File Dissertation/Dissertation.tex

 
 \subsection{Functional reactive programming}
 
-Functional reactive programming (FRP) was one of the initial inspirations for the project. A good introduction is given by~\cite{composing_reactive_animations}, which demonstrates how the principles can be applied to animation. In essence, functional reactive programming is a declarative way of specifying the relationships between different values. `Signals' which change over time are created and passed around as first-class values, and other values can then be defined as functions of these signals.
+Functional reactive programming (FRP) was one of the initial inspirations for the project. A good introduction is given by~\cite{composing_reactive_animations}, which demonstrates how the principles can be applied to animation. In essence, functional reactive programming is a declarative way of specifying the relationships between different values. `Signals' which change over time are created and passed around as first-class values, and other values can then be defined as functions of these signals. `Events', meanwhile, are discrete occurrences which the program can respond to.
 
 One of the main advantages of FRP is that it removes the need for explicitly defining how values are to be kept consistent and writing code to make this so. This is clearly solving a very similar problem to data binding, and so inspired the idea of making data binding more like FRP.
 
 
 Arrows were introduced by Hughes as a generalisation of `monads' in~\cite{hughes_arrows}. A monad takes the form \texttt{m a}, representing some computation which will give a result of type \texttt{a}~\cite{monads}. These are often useful in representing sequences of operations and those which involve side-effects. The basic monad type interface provides an identity function, which gives a monad returning whatever its input was, and a means of chaining monadic functions together. One way of viewing these is as a way of letting the programmer chain together functions in a way controlled by the monad -- for instance, the monad could be written to ensure that some form of global state is passed through along with the function results, or it could be used to handle error conditions without the programmer needing to write extra code for this. In all cases it is essentially handling some side-effect or background operation for the programmer, allowing them to chain various operations together without explicitly handling the side-effects.
 
-Arrows represent a generalisation of monads, in the sense that any monad can be equivalently implemented as an arrow. However, an arrow is of the form \texttt{arrow b c}, taking an input of type \texttt{b} and transforming it into an output of type \texttt{c}. The basic operators are similar: an \texttt{arr} operator takes a function as an argument and returns the arrow representing that function, and the \texttt{>>>} operator chains two arrows together such that the output of the first is passed through the second. Further to these, the \texttt{first} operator takes an \texttt{arrow b c} and returns an \texttt{arrow (b, d) (c, d)} -- an arrow taking a pair and applying the original arrow only to the first element of the pair. With these basic operators, a number of more complex standard operators can be built up. These are discussed in Section \ref{sec:simple_arrow_implementation} on the implementation of arrows.
+Arrows represent a generalisation of monads, in the sense that any monad can be equivalently implemented as an arrow. However, an arrow is of the form \texttt{arrow b c}, taking an input of type \texttt{b} and transforming it into an output of type \texttt{c}. The basic operators are similar: an \texttt{arr} operator takes a function as an argument and returns the arrow representing that function, and the \texttt{>>>} operator chains two arrows together such that the output of the first is passed through the second. Further to these, the \texttt{first} operator can be used to turn an arrow into an arrow on pairs by applying it to only the first element of the pair -- that is, taking an input \texttt{(a, b)} and giving \texttt{(f(a), b)} as output. This effectively creates a second `channel' through the arrow which is unaffected by it, and is used for constructing arrows which apply different functions to each element of a tuple. With these basic operators, a number of more complex standard operators can be built up. These are discussed in Section \ref{sec:simple_arrow_implementation} on the implementation of arrows.
 
-Arrows were selected for this project as the semantic nature of an \texttt{arrow a b} is simply a transformation from an input of type \texttt{a} to an output of type \texttt{b}, an interpretation which works well as a generalised model of the nature of data binding.
+Arrows were selected for this project as the semantic nature of an \texttt{arrow a b} is simply a transformation from an input of type \texttt{a} to an output of type \texttt{b}, an interpretation which works well as a generalised model of the nature of data binding. As all arrow combinators are implemented using the basic operators, the abstraction can be re-used for special arrows which implement extra functionality (for instance, stream processing or static analysis) simply by re-implementing the basic functions. This generality and re-usability came in handy in implementing invertible and list arrows later in the project (see Section \ref{sec:arrows}).
 
 \section{Requirements analysis}
 
 The implementation work consisted of two main parts: the arrows and the binding framework. As mentioned above, these were both initially developed through repeated iterations as different strategies were being investigated and new options discovered. This chapter describes the main development work and highlights the various difficulties encountered along the way.
 
 
-\section{Arrows}
+\section{Arrows} \label{sec:arrows}
 
 \subsection{Overview} \label{sec:arrows_overview}
 
 
 It was therefore decided that arrows and combinators should all be statically typed, as this would allow the compiler to do type checking and lead to much cleaner code. However, this meant the issue of the programmer having to provide long lists of type parameters to every combinator was still there. I was eventually able to solve this problem by writing the combinators in such a way that the compiler could always infer types from the arguments without the programmer needing to supply them. Several more situations were fixed by including static extension methods\footnote{Extension methods essentially allow you to define methods which act as though they belong to the object being passed in to them -- see~\cite{extension_methods} for a full explanation} which would use the source object to infer some parameters, and a series of static helper methods were included in the class \texttt{Op} to help fill in the gaps. This was easier said than done in several cases (which will be discussed later), but ultimately I managed to eliminate type parameters completely from the syntax. The resulting syntax for simple arrows is detailed in Section \ref{sec:simple_arrow_implementation}.
 
-A further problem was how best to allow arrows from multiple inputs to multiple outputs. Simply having a \texttt{Func} with multiple inputs would not have worked as the arrow would have had to be rewritten for every given number of inputs, and to make matters worse \texttt{Func} is limited to one output. For some time I debated writing a generic binary-tree-structured type\footnote{All arrows work on nested pairs} to handle this, but on discovering C$\sharp$'s built-in \texttt{Tuple<T1, T2>} type I felt this would be the simplest option. This ended up complicating the data binding (as I will discuss later), but was entirely sufficient for supporting the arrow implementation.
+A further problem was how best to allow arrows from multiple inputs to multiple outputs. Simply having a \texttt{Func} with multiple inputs would not have worked as \texttt{Func} objects with differing numbers of arguments are actually different types, so the arrow class would have had to be rewritten for every given number of inputs. To make matters worse, \texttt{Func} is also limited to one output. For some time I debated writing a generic binary-tree-structured type\footnote{All arrows work on nested pairs} to handle this, but on discovering C$\sharp$'s built-in \texttt{Tuple<T1, T2>} type I felt this would be the simplest option. This ended up complicating the data binding (as I will discuss later), but was entirely sufficient for supporting the arrow implementation.
 
 \subsection{Simple arrows} \label{sec:simple_arrow_implementation}
 
 \begin{figure}[!ht]
   \centering
   \includegraphics[width=50mm]{fig/ArrOperator.pdf}
-  \caption{The Arr operator}
+  \caption[The Arr operator]{The Arr operator. The circled \texttt{f} is the function it performs, and the box around it indicates that it is boxed as an arrow with inputs on the left and outputs on the right.}
   \label{fig:arr_operator}
 \end{figure}
 
 \begin{figure}[!ht]
   \centering
   \includegraphics[width=50mm]{fig/CompositionOperator.pdf}
-  \caption{The Combine operator}
+  \caption[The Combine operator]{The Combine operator. The path of data through the functions is indicated by arrows.}
   \label{fig:combine_operator}
 \end{figure}
 
 \begin{figure}[!ht]
   \centering
   \includegraphics[width=50mm]{fig/FirstOperator.pdf}
-  \caption{The First operator}
+  \caption[The First operator]{The First operator. Here there is a second input to the arrow which is unaffected by the original arrow's function.}
   \label{fig:first_operator}
 \end{figure}
 
 var parallelArrow = leftArrow.And(rightArrow);
 \end{lstlisting}
 
+This is commonly thought of as combining leftArrow and rightArrow side-by-side by calling \texttt{first leftArrow} and passing its output into \texttt{second rightArrow}. Figure \ref{fig:and_operator} illustrates this, where the arrows are implementing functions \texttt{f} and \texttt{g}.
+
 \begin{figure}[!ht]
   \centering
   \includegraphics[width=50mm]{fig/AndOperator.pdf}
 
 To tackle this problem, I implemented a \texttt{BindingGraph} class which is used by the \texttt{BindingsManager} and keeps track of the topology of all the existing bindings (leaving the details of actual bind points to the bindings manager). Whenever a new binding is added or an old binding is removed, the binding graph is notified and it updates its map of the bindings appropriately. It then provides methods which allow the bindings manager to query whether a new binding will introduce a cycle or conflict, and if so the bindings manager will know to abort the binding with an exception.
 
-Both cycles and conflicts can be reduced to the same question: for each node in the binding graph, is there another node which is reachable from it via more than one path? Both situations are therefore handled by the same algorithm, which proceeds by depth-first searching from each node and maintaining a set of nodes which have been seen along the way. Rough pseudocode for this method is given in Listing~\ref{lst:cycle_conflict_pseudocode}.
+Both cycles and conflicts can be reduced to the same question: for each node in the binding graph, is there another node which is reachable from it via more than one path? (This covers cycles as any node in the cycle can be reached by traversing the cycle any number of times.) Both situations are therefore handled by the same algorithm, which proceeds by depth-first searching from each node and maintaining a set of nodes which have been seen along the way. Rough pseudocode for this method is given in Listing~\ref{lst:cycle_conflict_pseudocode}.
 
 \begin{lstlisting}[caption={Pseudocode for cycle and conflict detection}, label=lst:cycle_conflict_pseudocode]
 for each node in the graph:
 
 \subsubsection{Many-to-many bindings} \label{sec:many_many_bindings}
 
-Many-to-many bindings presented an additional challenge for the binding system. It was decided that the best approach in terms of syntax would be to have the user pass in a list of source bind points, an arrow and a list of destination bind points, so as to mirror the syntax used in simple bindings. However, this simple approach is out of step with the way parameters are passed to arrows: by construction, all arrows taking multiple inputs will take them in the form of a binary-tree-structured Tuple\footnote{This can be verified by looking at the implementations of the operators; for instance, And converts two arrows (which may be on tuples) into an arrow on two-tuples containing the types of the original arrows, thus building up a binary tree structure}. As there didn't appear to be any C$\sharp$ syntax allowing the user to pass in binding sources in a similar fashion (such that the structure could be understood by the binding), it was decided that an argument marshaller/unmarshaller would be needed to handle the translation between lists of bind points and tree-structured tuples.
+Many-to-many bindings occur where multiple sources have effects on multiple destinations -- for example, a display showing the sum of several variables, or a series of components which are bound to a shared data structure. For flexibility, the framework allows arbitrarily many destinations to be bound to arbitrarily many destinations. It was decided that the best approach in terms of syntax would be to have the user pass in a list of source bind points, an arrow and a list of destination bind points, so as to mirror the syntax used in simple bindings. However, this simple approach is out of step with the way parameters are passed to arrows: by construction, all arrows taking multiple inputs will take them in the form of a binary-tree-structured Tuple\footnote{This can be verified by looking at the implementations of the operators; for instance, And converts two arrows (which may be on tuples) into an arrow on two-tuples containing the types of the original arrows, thus building up a binary tree structure}. As there didn't appear to be any C$\sharp$ syntax allowing the user to pass in binding sources in a similar fashion (such that the structure could be understood by the binding), it was decided that an argument marshaller/unmarshaller would be needed to handle the translation between lists of bind points and tree-structured tuples.
 
 \begin{figure}[!ht]
   \centering
 Arr Split >>> (square *** square) >>> Arr Unsplit(add)
 \end{lstlisting}
 
-It therefore seems reasonable to conclude that the syntax is as clean as C$\sharp$ allows without significant workarounds, and though it may not match the cleaner Haskell syntax this is largely due to the differences between the languages. One option that was considered for improving the syntax was Miscrosoft's Roslyn library\footnote{http://msdn.microsoft.com/en-us/vstudio/hh500769}, which allows the programmer to modify the syntax tree of the code being compiled and thus introduce extra syntactic constructs. However, Roslyn is not yet fully functional and it was decided that the complexity involved would almost be a second project in its own right. The possibility remains for future work to attempt this direction once Roslyn is complete.
+It therefore seems reasonable to conclude that the syntax is as clean as C$\sharp$ allows without significant workarounds, and though it may not match the cleaner Haskell syntax this is largely due to the differences between the languages. One option that was considered for improving the syntax was Microsoft's Roslyn library\cite{roslyn}, which allows the programmer to modify the syntax tree of the code being compiled and thus introduce extra syntactic constructs. However, Roslyn is not yet fully functional and it was decided that the complexity involved would almost be a second project in its own right. The possibility remains for future work to attempt this direction once Roslyn is complete.
 
 \subsection{Binding syntax}
 

File Dissertation/Dissertation.toc

 \contentsline {subsection}{\numberline {3.2.5}Further utility arrows}{16}
 \contentsline {section}{\numberline {3.3}Data binding}{17}
 \contentsline {subsection}{\numberline {3.3.1}Overall architecture}{17}
-\contentsline {subsection}{\numberline {3.3.2}Creating bindable sources and destinations}{17}
-\contentsline {subsection}{\numberline {3.3.3}Creating bindings}{19}
+\contentsline {subsection}{\numberline {3.3.2}Creating bindable sources and destinations}{18}
+\contentsline {subsection}{\numberline {3.3.3}Creating bindings}{20}
 \contentsline {subsubsection}{Syntax and usage}{20}
 \contentsline {subsubsection}{Two-way binding}{21}
 \contentsline {subsubsection}{Cycle and conflict detection}{21}

File Dissertation/texput.log

-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  8 MAY 2013 14:54
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  9 MAY 2013 15:48
 entering extended mode
 **Bibliography.tex