1. David Barker
  2. C# Arrows

Commits

David Barker  committed f01d727

Started making changes suggested by Tomas

  • Participants
  • Parent commits b88380a
  • Branches master

Comments (0)

Files changed (10)

File ArrowDataBinding.v11.suo

Binary file modified.

File Dissertation/Bibliography.bib

View file
   title        = {{Composing Reactive Animations}},
   journal      = {Dr. Dobb's Journal},
   year         = {1998},
-  note         = {Also in expanded animated form at http://conal.net/fran/tutorial.htm}
+  note         = {Also in expanded animated form at \url{http://conal.net/fran/tutorial.htm}}
 }
 
 @misc{haskell_arrows,
   author = {Ross Paterson},
   title = {{Arrows: A General Interface to Computation}},
-  note = {http://www.haskell.org/arrows (accessed on 24/04/2013)}
+  note = {\url{http://www.haskell.org/arrows} (accessed on 24/04/2013)}
 }
 
 @incollection{arrows_and_computation,
 @misc{wpf_data_binding_overview,
   author = {MSDN},
   title = {{Data Binding Overview}},
-  note = {http://msdn.microsoft.com/en-us/library/ms752347.aspx (accessed on 24/04/2013)}
+  note = {\url{http://msdn.microsoft.com/en-us/library/ms752347.aspx} (accessed on 24/04/2013)}
 }
 
 @misc{javascript_data_binding,
   author = {yap.TV},
   title = {{Javascript Frameworks and Data Binding}},
-  note = {http://tunein.yap.tv/javascript/2012/06/11/javascript-frameworks-and-data-binding/ (accessed on 24/04/2013)}
+  note = {\url{http://tunein.yap.tv/javascript/2012/06/11/javascript-frameworks-and-data-binding/} (accessed on 24/04/2013)}
 }
 
 @incollection{functional_reactive_programming,
 @misc{monads,
 	title = {{Monads as Computation}},
 	author = {Haskell Wiki},
-	note = {http://www.haskell.org/haskellwiki/Monads\_as\_computation (accessed on 30/04/2013)}
+	note = {\url{http://www.haskell.org/haskellwiki/Monads_as_computation} (accessed on 30/04/2013)}
 }
 
 @misc{fogbugz,
 	title = {{FogBugz}},
 	author = {FogCreek Software},
-	note = {http://www.fogcreek.com/fogbugz (accessed on 30/04/2013)}
+	note = {\url{http://www.fogcreek.com/fogbugz} (accessed on 30/04/2013)}
 }
 
 @misc{bitbucket,
 	title = {{BitBucket}},
 	author = {BitBucket},
-	note = {http://www.bitbucket.org (accessed on 30/04/2013)}
+	note = {\url{http://www.bitbucket.org} (accessed on 30/04/2013)}
 }
 
 @misc{total_processor_time,
 	title = {{Processor.TotalProcessorTime Property}},
 	author = {MSDN},
-	note = {http://msdn.microsoft.com/en-us/library/system.diagnostics.process.totalprocessortime.aspx (accessed on 30/04/2013)}
+	note = {\url{http://msdn.microsoft.com/en-us/library/system.diagnostics.process.totalprocessortime.aspx} (accessed on 30/04/2013)}
 }
 
 @misc{extension_methods,
 	title = {{Extension Methods}},
 	author = {MSDN},
-	note = {http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx (accessed on 30/04/2013)}
+	note = {\url{http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx} (accessed on 30/04/2013)}
 }
 
 @misc{postsharp_propertychanged,
 	title = {{Automatically Implementing INotifyPropertyChanged}},
 	author = {PostSharp Documentation},
-	note = {http://www.postsharp.net/model/inotifypropertychanged (accessed on 30/04/2013)}
+	note = {\url{http://www.postsharp.net/model/inotifypropertychanged} (accessed on 30/04/2013)}
 }
 
 @misc{postsharp_locationinterception,
 	title = {{LocationInterceptionAspect Class}},
 	author = {PostSharp Documentation},
-	note = {http://doc.postsharp.net//postsharp-2.1/Default.aspx\#\#PostSharp-2.1.chm/html/T\_PostSharp\_Aspects\_LocationInterceptionAspect.htm (accessed on 30/04/2013)}
+	note = {\url{http://doc.postsharp.net//postsharp-2.1/Default.aspx##PostSharp-2.1.chm/html/T_PostSharp_Aspects_LocationInterceptionAspect.htm (accessed on 30/04/2013)}}
 }
 
 @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 = {\\http://www.codeproject.com/Articles/337564/Aspect-Oriented-Programming-Using-Csharp-and-PostS}
 }
 
 @misc{haskell_wiki_arrows,
-	title = {Control.Arrow},
+	title = {{Control.Arrow}},
 	author = {Haskell Wiki},
-	note = {http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html}
+	note = {\\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}
 }

File Dissertation/Dissertation.aux

View file
 \relax 
 \bibstyle{plain}
+\citation{mvvm}
 \@writefile{toc}{\contentsline {chapter}{\numberline {1}Introduction}{1}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
 \bibcite{haskell_arrows}{15}
 \bibcite{arrow_notation}{16}
 \bibcite{arrows_and_computation}{17}
-\bibcite{fogbugz}{18}
-\bibcite{frp_first_principles}{19}
-\bibcite{haskell_wiki_arrows}{20}
-\bibcite{monads}{21}
+\bibcite{mvvm}{18}
+\bibcite{fogbugz}{19}
+\bibcite{frp_first_principles}{20}
+\bibcite{haskell_wiki_arrows}{21}
+\bibcite{monads}{22}
 \@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
 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.
+  \\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
 \bibitem{bitbucket}
 BitBucket.
 \newblock {BitBucket}.
-\newblock http://www.bitbucket.org (accessed on 30/04/2013).
+\newblock \url{http://www.bitbucket.org} (accessed on 30/04/2013).
 
 \bibitem{postsharp_propertychanged}
 PostSharp Documentation.
 \newblock {Automatically Implementing INotifyPropertyChanged}.
-\newblock http://www.postsharp.net/model/inotifypropertychanged (accessed on
-  30/04/2013).
+\newblock \url{http://www.postsharp.net/model/inotifypropertychanged} (accessed
+  on 30/04/2013).
 
 \bibitem{postsharp_locationinterception}
 PostSharp Documentation.
 \newblock {LocationInterceptionAspect Class}.
 \newblock
-  http://doc.postsharp.net//postsharp-2.1/Default.aspx\#\#PostSharp-2.1.chm/html/T\_PostSharp\_Aspects\_LocationInterceptionAspect.htm
-  (accessed on 30/04/2013).
+  \url{http://doc.postsharp.net//postsharp-2.1/Default.aspx##PostSharp-2.1.chm/html/T_PostSharp_Aspects_LocationInterceptionAspect.htm
+  (accessed on 30/04/2013)}.
 
 \bibitem{composing_reactive_animations}
 Conal Elliott.
 \newblock {Composing Reactive Animations}.
 \newblock {\em Dr. Dobb's Journal}, 1998.
-\newblock Also in expanded animated form at http://conal.net/fran/tutorial.htm.
+\newblock Also in expanded animated form at
+  \url{http://conal.net/fran/tutorial.htm}.
 
 \bibitem{functional_reactive_programming}
 Paul Hudak.
 \bibitem{wpf_data_binding_overview}
 MSDN.
 \newblock {Data Binding Overview}.
-\newblock http://msdn.microsoft.com/en-us/library/ms752347.aspx (accessed on
-  24/04/2013).
+\newblock \url{http://msdn.microsoft.com/en-us/library/ms752347.aspx} (accessed
+  on 24/04/2013).
 
 \bibitem{extension_methods}
 MSDN.
 \newblock {Extension Methods}.
-\newblock http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx
+\newblock \url{http://msdn.microsoft.com/en-us/library/vstudio/bb383977.aspx}
   (accessed on 30/04/2013).
 
 \bibitem{total_processor_time}
 MSDN.
 \newblock {Processor.TotalProcessorTime Property}.
 \newblock
-  http://msdn.microsoft.com/en-us/library/system.diagnostics.process.totalprocessortime.aspx
+  \url{http://msdn.microsoft.com/en-us/library/system.diagnostics.process.totalprocessortime.aspx}
   (accessed on 30/04/2013).
 
 \bibitem{haskell_arrows}
 Ross Paterson.
 \newblock {Arrows: A General Interface to Computation}.
-\newblock http://www.haskell.org/arrows (accessed on 24/04/2013).
+\newblock \url{http://www.haskell.org/arrows} (accessed on 24/04/2013).
 
 \bibitem{arrow_notation}
 Ross Paterson.
 \newblock In Jeremy Gibbons and Oege de~Moor, editors, {\em The Fun of
   Programming}, pages 201--222. Palgrave, 2003.
 
+\bibitem{mvvm}
+Josh Smith.
+\newblock {WPF Apps With The Model-View-ViewModel Design Pattern}.
+\newblock \\http://msdn.microsoft.com/en-us/magazine/dd419663.aspx.
+
 \bibitem{fogbugz}
 FogCreek Software.
 \newblock {FogBugz}.
-\newblock http://www.fogcreek.com/fogbugz (accessed on 30/04/2013).
+\newblock \url{http://www.fogcreek.com/fogbugz} (accessed on 30/04/2013).
 
 \bibitem{frp_first_principles}
 Zhanyong Wan and Paul Hudak.
 
 \bibitem{haskell_wiki_arrows}
 Haskell Wiki.
-\newblock Control.arrow.
+\newblock {Control.Arrow}.
 \newblock
-  http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html.
+  \\http://www.haskell.org/ghc/docs/latest/html/libraries/base/Control-Arrow.html.
 
 \bibitem{monads}
 Haskell Wiki.
 \newblock {Monads as Computation}.
-\newblock http://www.haskell.org/haskellwiki/Monads\_as\_computation (accessed
-  on 30/04/2013).
+\newblock \url{http://www.haskell.org/haskellwiki/Monads_as_computation}
+  (accessed on 30/04/2013).
 
 \end{thebibliography}

File Dissertation/Dissertation.blg

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

File Dissertation/Dissertation.log

View file
-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  7 MAY 2013 20:46
+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
 entering extended mode
 **Dissertation.tex
 
 \pc@columncount=\count98
 \pc@everypar=\toks18
 )
+("C:\Program Files\MiKTeX 2.9\tex\latex\ltxmisc\url.sty"
+\Urlmuskip=\muskip10
+Package: url 2006/04/12  ver 3.3  Verb mode for urls, etc.
+)
 ("C:\Users\David\Documents\Visual Studio 2010\Projects\ArrowDataBinding\Dissert
 ation\Dissertation.aux"
 
 LaTeX Warning: Label `postsharp' multiply defined.
 
 )
-LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
-LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
-LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
-LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
-LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
-LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 28.
-LaTeX Font Info:    ... okay on input line 28.
+LaTeX Font Info:    Checking defaults for OML/cmm/m/it on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
+LaTeX Font Info:    Checking defaults for T1/cmr/m/n on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
+LaTeX Font Info:    Checking defaults for OT1/cmr/m/n on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
+LaTeX Font Info:    Checking defaults for OMS/cmsy/m/n on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
+LaTeX Font Info:    Checking defaults for OMX/cmex/m/n on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
+LaTeX Font Info:    Checking defaults for U/cmr/m/n on input line 29.
+LaTeX Font Info:    ... okay on input line 29.
  ("C:\Program Files\MiKTeX 2.9\tex\context\base\supp-pdf.mkii"
 [Loading MPS to PDF converter (version 2006.09.02).]
 \scratchcounter=\count99
 )
 \c@lstlisting=\count105
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <24.88> on input line 44.
+(Font)              <24.88> on input line 45.
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <20.74> on input line 44.
+(Font)              <20.74> on input line 45.
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <17.28> on input line 44.
+(Font)              <17.28> on input line 45.
  [1
 
 {C:/ProgramData/MiKTeX/2.9/pdftex/config/pdftex.map}] [2
 
 ]
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <14.4> on input line 65.
+(Font)              <14.4> on input line 66.
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <7> on input line 65.
+(Font)              <7> on input line 66.
 
-Underfull \hbox (badness 10000) in paragraph at lines 65--76
+Underfull \hbox (badness 10000) in paragraph at lines 66--77
 []
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 65--76
+Underfull \hbox (badness 10000) in paragraph at lines 66--77
 
  []
 
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <12> on input line 80.
+(Font)              <12> on input line 81.
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <8> on input line 80.
+(Font)              <8> on input line 81.
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <6> on input line 80.
+(Font)              <6> on input line 81.
 [1
 
 ] [2] [3] [4
 
 ]
 LaTeX Font Info:    External font `cmex10' loaded for size
-(Font)              <5> on input line 146.
+(Font)              <5> on input line 147.
  [2] [3] [4
 
 ]
 File: fig/ArrOperator.pdf Graphic file (type pdf)
 
 <use fig/ArrOperator.pdf>
-Package pdftex.def Info: fig/ArrOperator.pdf used on input line 241.
+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>
 File: fig/CompositionOperator.pdf Graphic file (type pdf)
 
 <use fig/CompositionOperator.pdf>
-Package pdftex.def Info: fig/CompositionOperator.pdf used on input line 254.
+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 262.
+(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 259.
 
 <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 273.
+Package pdftex.def Info: fig/FirstOperator.pdf used on input line 270.
 (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 288.
+Package pdftex.def Info: fig/AndOperator.pdf used on input line 285.
 (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 426.
+Package pdftex.def Info: fig/BindingFramework.pdf used on input line 423.
 (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 491.
+LaTeX Font Info:    Try loading font information for OMS+cmr on input line 488.
 
  ("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 491.
+(Font)              Font shape `OMS/cmsy/m/n' tried instead on input line 488.
  [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 523.
+Package pdftex.def Info: fig/ArgumentMarshalling.pdf used on input line 520.
 (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 558.
+Package pdftex.def Info: fig/WPFIntegrationDemo.png used on input line 555.
 (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 683.
+Package pdftex.def Info: fig/CaseStudyNameBinding.png used on input line 680.
 (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 704.
+Package pdftex.def Info: fig/CaseStudyListBinding.png used on input line 701.
 (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 761.
+ine 758.
 (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 780.
+e 777.
 (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 794.
+Package pdftex.def Info: fig/IdentityChains.pdf used on input line 791.
 (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 1509) in paragraph at lines 4--8
-[]\OT1/cmr/m/n/12 Reza Ah-madi.  As-pect Ori-ented Pro-gram-ming Us-ing C$\OML/
-cmm/m/it/12 ]$ \OT1/cmr/m/n/12 and Post-
+Underfull \hbox (badness 10000) in paragraph at lines 4--8
+\OT1/cmr/m/n/12 http://www.codeproject.com/Articles/337564/Aspect-Oriented-
  []
 
 
-Underfull \hbox (badness 3919) in paragraph at lines 4--8
-\OT1/cmr/m/n/12 Sharp.  http://www.codeproject.com/Articles/337564/Aspect-Orien
-ted-
- []
-
-
-Underfull \hbox (badness 10000) in paragraph at lines 28--33
-[]\OT1/cmr/m/n/12 PostSharp Doc-u-men-ta-tion.  Lo-ca-tion-In-ter-cep-tionAspec
-t Class.
+Underfull \hbox (badness 3735) in paragraph at lines 17--20
+[]\OT1/cmr/m/n/12 BitBucket.  Bit-Bucket.  $\OT1/cmtt/m/n/12 http : / / www . b
+itbucket . org$ \OT1/cmr/m/n/12 (ac-cessed on
  []
 
 
 Underfull \hbox (badness 10000) in paragraph at lines 28--33
-\OT1/cmr/m/n/12 http://doc.postsharp.net//postsharp-2.1/Default.aspx##PostSharp
--
+$\OT1/cmtt/m/n/12 / / doc . postsharp . net / /postsharp -[] 2 . 1 / Default . 
+aspx # #PostSharp -[]$
  []
 
 
 Underfull \hbox (badness 10000) in paragraph at lines 28--33
-\OT1/cmr/m/n/12 2.1.chm/html/T[]PostSharp[]Aspects[]LocationInterceptionAspect.
-htm
+$\OT1/cmtt/m/n/12 2 . 1 . chm / html / T _ PostSharp _ Aspects _ LocationInterc
+eptionAspect .$
  []
 
 [45
 
 ]
-Underfull \hbox (badness 4072) in paragraph at lines 70--74
-[]\OT1/cmr/m/n/12 MSDN.  Data Bind-ing Overview.  http://msdn.microsoft.com/en-
-
+Underfull \hbox (badness 2245) in paragraph at lines 77--81
+[]\OT1/cmr/m/n/12 MSDN.  Ex-ten-sion Meth-ods.  $\OT1/cmtt/m/n/12 http : / / ms
+dn . microsoft . com / en -[] us /$
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 76--80
-[]\OT1/cmr/m/n/12 MSDN.  Ex-ten-sion Meth-ods.  http://msdn.microsoft.com/en-
+Underfull \hbox (badness 7777) in paragraph at lines 83--88
+[]\OT1/cmr/m/n/12 MSDN.  Pro-ces-sor.TotalProcessorTime Prop-erty.  $\OT1/cmtt/
+m/n/12 http : / / msdn .$
  []
 
 
-Underfull \hbox (badness 10000) in paragraph at lines 82--87
-[]\OT1/cmr/m/n/12 MSDN.  Pro-ces-sor.TotalProcessorTime Prop-erty.
- []
-
-
-Overfull \hbox (88.86714pt too wide) in paragraph at lines 82--87
-\OT1/cmr/m/n/12 http://msdn.microsoft.com/en-us/library/system.diagnostics.proc
-ess.totalprocessortime.aspx
- []
-
-
-Underfull \hbox (badness 4765) in paragraph at lines 89--92
-[]\OT1/cmr/m/n/12 Ross Pa-ter-son.  Ar-rows: A Gen-eral In-ter-face to Com-pu-t
-a-tion.
- []
-
-
-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 83--88
+$\OT1/cmtt/m/n/12 microsoft . com / en -[] us / library / system . diagnostics 
+. process .$
  []
 
 
 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
+\OT1/cmr/m/n/12 http://www.haskell.org/ghc/docs/latest/html/libraries/base/Cont
+rol-
  []
 
 ) [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 977.
+(Font)              Font shape `OT1/cmtt/m/n' tried instead on input line 974.
 [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 1021.
+ne 1018.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1021.
+ne 1018.
 [53
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1076.
+ne 1073.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1076.
+ne 1073.
  [54]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1121.
+ne 1118.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1121.
+ne 1118.
  [55] [56]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1163.
+ne 1160.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1163.
+ne 1160.
  [57
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1205.
+ne 1202.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1205.
+ne 1202.
  [58]
 Appendix D.
 
 
  ) 
 Here is how much of TeX's memory you used:
- 3005 strings out of 494045
- 44406 string characters out of 3148387
+ 3079 strings out of 494045
+ 45292 string characters out of 3148387
  245619 words of memory out of 3000000
- 6271 multiletter control sequences out of 15000+200000
+ 6341 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, 597983 bytes).
+Output written on Dissertation.pdf (78 pages, 599313 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

View file
 \setcounter{tocdepth}{5}
 
 \usepackage{parcolumns}
+\usepackage[hyphens]{url}
 
 \begin{document}
 
 
 \chapter{Introduction}
 
-It has become a firmly established practice when writing applications to separate the code managing the user interface from the business logic powering it. This is a key part of the principle of separation of concerns, and means that the interface can be safely changed without needing to modify the backend code (and vice versa, assuming the backend provides a consistent interface). Beginning with the traditional MVC architecture, this has led to the development of a family of system architectures such as MVPM and MVVM which enforce this principle.
+It has become a firmly established practice when writing applications to separate the code managing the user interface from the business logic powering it. This is a key part of the principle of separation of concerns, and means that the interface can be safely changed without needing to modify the backend code (and vice versa, assuming the backend provides a consistent interface). Beginning with the traditional MVC architecture, this has led to the development of a family of system architectures such as MVPM and MVVM~\cite{mvvm} which enforce this principle.
 
 \section{Data binding}
 
 
 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.
-%TODO Maybe more disadvantages?
+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 (essentially using the Strategy 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 make application development simpler.
 
 \section{Project inspirations}
 
-Many useful ideas for data binding come from the area of functional programming. Functional reactive programming (FRP), for example, is a paradigm which nicely models the concept of data binding in a general way. Another useful concept is that of the `arrows' implemented in Haskell. An `arrow from type A to type B' essentially represents a process taking an input of type A and returning something of type B, and these can be arbitrarily combined in interesting ways to build up complex functions. More detail on both will be given in the next chapter.
+Many useful ideas for data binding come from the area of functional programming. Functional reactive programming (FRP), for example, is a paradigm which nicely models the concept of data binding in a general way. Another useful concept is that of the `arrows' implemented in Haskell. An `arrow from type A to type B' represents a process taking an input of type A and returning something of type B, and these can be arbitrarily combined in interesting ways to build up complex functions. More detail on both will be given in the next chapter.
 
 The FRP paradigm was the inspiration for the project, which sought to implement a general-purpose data binding framework in C$\sharp$ using concepts derived from functional programming. I successfully implemented a framework which provides data binding in both directions, through arbitrary functions with arbitrary numbers of inputs and outputs, all with a simple syntax based on lambda expressions. Minimal boilerplate code is required to set up bindable properties -- the containing class should extend \texttt{Bindable}, and from there marking arbitrary member variables and properties with the \texttt{[Bindable]} tag will make it possible to create bindings to and from them with a single function call. I also implemented a large variety of arrow types and arrow operators along with a number of utility functions to make creating and combining them simple.
 
 
 \section{Requirements analysis}
 
-From the outset, the main objectives of the project were to make the data binding framework syntactically clear and free from boilerplate, and to make the arrows as powerful and easy to use as possible. Therefore, some time was spent at the beginning of the project establishing what could be done to achieve this and just what sort of functionality would likely be needed.
+From the outset, the main objectives of the project were to make the data binding framework syntactically clear and free from boilerplate, and to make the arrows as powerful and easy to use as possible. Therefore, some time was spent at the beginning of the project establishing what could be done to achieve this and what functionality would likely be needed.
 
-To start off, I spent some time understanding how data binding is already done in .NET's WPF framework. It was clear that the existing approach involved a lot of repetitive coding from the programmer to set up bindable sources and destinations, and there were several different conflicting ways of actually creating the binding -- either in the XAML code describing the user interface or in the code-behind. Thus I decided a good first objective would be to find a way of making the framework completely general, with one consistent way of creating bindings which handles all the situation-specific details itself. I also focussed on ways of removing the usual boilerplate code for creating sources and destinations, replacing it with a base class which manages events and interactions and an attribute which can be placed on properties the programmer wishes to bind.
+To start off, I spent some time understanding how data binding is already done in .NET's WPF framework. It was clear that the existing approach involved a lot of repetitive coding from the programmer to set up bindable sources and destinations\footnote{This is described in more detail in later sections}, and there were several different conflicting ways of actually creating the binding -- either in the XAML code describing the user interface or in the code-behind. Thus I decided a good first objective would be to find a way of making the framework completely general, with one consistent way of creating bindings which handles all the situation-specific details itself. I also focussed on ways of removing the usual boilerplate code for creating sources and destinations, replacing it with a base class which manages events and interactions and an attribute which can be placed on properties the programmer wishes to bind.
 
 I also investigated what sort of features modern data binding frameworks implement, and which would be most useful for an arrow-based one. Binding through functions is not a new concept by any means, and indeed two-way binding is already implemented in .NET. However, in most cases these are fairly messy to set up -- in .NET, for instance, large \texttt{ValueConverter} classes have to be written to perform the transformation. It was decided that the cleanest way of handling this would be simply requiring that all bindings have an arrow attached. This way, the syntax is consistent whether the binding is direct or functional, and of course it is easy to pass in an identity arrow for a non-functional binding.
 
 
 \subsection{Overview} \label{sec:arrows_overview}
 
-Implementing the highly functional idea of an arrow in C$\sharp$ posed an interesting challenge. Fundamentally, there were two main obstacles to overcome: C$\sharp$'s syntax, which is far clunkier than Haskell's; and the type system, which is far more restrictive and relies on static analysis at compile time. It was decided early on that arrows would be built on lambda expressions as these seemed the most natural way of expressing the desired functionality. C$\sharp$'s generic \texttt{Func<T1, T2>} type provided a good way of handling arbitrary lambda expressions between arbitrary types, and so this became the basis for the arrow type.
+Implementing the highly functional idea of an arrow in C$\sharp$ posed an interesting challenge. Fundamentally, there were two main obstacles to overcome: C$\sharp$'s syntax, which is far clunkier than Haskell's; and the type system, which is more restrictive and has greatly limited type inference capabilities. It was decided early on that arrows would be built on lambda expressions as these seemed the most natural way of expressing the desired functionality. C$\sharp$'s generic \texttt{Func<T1, T2>} type provided a good way of handling arbitrary lambda expressions between arbitrary types, and so this became the basis for the arrow type.
 
 Tackling the type system was particularly difficult. I initially took the approach of writing arrow combinator functions so that they required no type parameters and instead inferred all their types by reflection. This made the syntax far neater and, using some run-time type checking, could plausibly be made type safe (though the compiler would have no way of enforcing it). However, after some experimenting it became clear that writing new operators and arrow types would be particularly difficult using this approach, and the resulting code was very complicated and difficult to understand.
 
-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.
+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.
 
-%TODO
-%Maybe mention arrow intercompatibility?
-
 \subsection{Simple arrows} \label{sec:simple_arrow_implementation}
 
 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.
 
 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 periodically polling all bound variables to check for updates was also considered, but this was clearly no good: polling is system-intensive, and potentially wasteful when a number of variables bind to the same source. Furthermore, 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}.
+Conveniently, C$\sharp$ provides simple syntax for event-based programming. Events can be created for a class and triggered 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}.
 
 \begin{figure}[!ht]
   \centering
 
 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}.
+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 triggered 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 \texttt{Bindable}. The unfortunate side-effect of the \texttt{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}.
 
 	\item One property is directly or indirectly bound to more than one source through functions which will not necessarily yield the same result
 \end{itemize}
 
-The first scenario is especially problematic for this binding framework as binding updates are performed in the same thread, so a binding cycle will lead to an infinite loop of updates causing the application to freeze. The second scenario doesn't necessarily break the application, but the resulting behaviour will be entirely unpredictable\footnote{This is because the order in which bindings are updated is governed by the order in which C$\sharp$ delivers events, and this is outwith the programmer's control}. Naturally, a useful data binding framework would need to handle these situations properly.
+The first scenario is especially problematic for this binding framework as binding updates are performed in the same thread, so a binding cycle will lead to an infinite loop of updates causing the application to freeze. The second scenario doesn't necessarily break the application, but the resulting behaviour will be entirely unpredictable\footnote{This is because the order in which bindings are updated is governed by the order in which C$\sharp$ delivers events, and this is outwith the programmer's control}.
 
 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.
 
 
 Primarily, Haskell has a complex type inference system with a lot of features C$\sharp$ lacks. The main problem on that front was not having polymorphic types, as these are vital in implementing a general-purpose identity arrow or swap arrow. The lack of polymorphic types was also the reason the \texttt{First} operator was so difficult to implement cleanly. Another issue was the fact that C$\sharp$ methods must always be called on an object or class, and have strict syntax rules meaning the arguments must be bracketed after the call (precluding neat currying syntax). Thirdly, C$\sharp$ doesn't allow the programmer to create custom operators like `\texttt{>>>}' for arrow composition.
 
-For illustration, consider a fairly elaborate arrow constructed to compute the value $2x^2$ given an input $x$. In Haskell this might be rendered as follows:
+For illustration, consider a fairly elaborate arrow constructed to compute the value $2x^2$ given an input $x$. For the sake of adding complexity, it duplicates the input into a tuple, squares both elements and then adds the two results together to yield the final value. In Haskell this might be rendered as follows:
 
 \begin{lstlisting}
 (arr split) >>> (square *** square) >>> arr (unsplit (+))
 
 \section{Final words}
 
-Overall, the project clearly still has some way to go before it's usable and efficient enough to be a complete alternative to WPF. But despite this, I think it was definitely successful in its goals of bringing a largely complete arrow implementation to C$\sharp$ and providing a powerful general-purpose data binding framework. The result has very minimal boilerplate code and allows for a large range of complex functional bindings, which would be very difficult to implement with plain WPF binding.
+Overall, the project clearly still has some way to go before it's usable and efficient enough to be a complete alternative to WPF data binding. But despite this, I think it was definitely successful in its goals of bringing a largely complete arrow implementation to C$\sharp$ and providing a powerful general-purpose data binding framework. The result has very minimal boilerplate code and allows for a large range of complex functional bindings, which would be very difficult to implement with plain WPF binding.
 
 In general, it's not clear how well a FRP-based system would fit in with traditional OOP principles. The system implemented requires a lot of dynamic typing and type inference, which are very rarely found in current OOP languages like Java or C++. The solution of using reflection is also not type-safe and is prone to error. However, recent versions of the .NET framework have featured increasing amounts of type inference -- for instance, the \texttt{var} keyword which tells the compiler to infer the correct type, and the \texttt{dynamic} keyword which allows for dynamic typing (both of these were invaluable to this project). Meanwhile, Java 8 now includes lambda expressions, and Scala is a language which is both OOP and functional, so it is clear that functional language features are gaining popularity in mainstream languages. I intend to continue work on the improvements suggested above, and hope to see functional programming ideas continue to become more widespread in similar areas over the coming years.
 

File Dissertation/texput.log

View file
-This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  30 APR 2013 15:42
+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
 entering extended mode
 **Bibliography.tex