Commits

David Barker committed e6b79e1

Wrote conclusion

  • Participants
  • Parent commits 6ff2662

Comments (0)

Files changed (6)

File Dissertation/Dissertation.aux

 \newlabel{lst:cycle_conflict_pseudocode}{{3.3}{22}}
 \@writefile{lol}{\contentsline {lstlisting}{\numberline {3.3}Pseudocode for cycle and conflict detection}{22}}
 \@writefile{toc}{\contentsline {subsubsection}{Many-to-many bindings}{22}}
+\newlabel{sec:many_many_bindings}{{3.3.3}{22}}
 \@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{toc}{\contentsline {subsubsection}{Problems encountered}{23}}
 \@writefile{toc}{\contentsline {section}{\numberline {4.2}Syntax evaluation}{29}}
 \@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}}
 \@writefile{toc}{\contentsline {subsection}{\numberline {4.2.2}Binding syntax}{31}}
 \@writefile{toc}{\contentsline {subsubsection}{Username two-way binding}{31}}
 \@writefile{lof}{\contentsline {figure}{\numberline {4.1}{\ignorespaces The username two-way binding application}}{32}}
 \newlabel{sec:arrow_chaining_overhead}{{4.3.1}{37}}
 \@writefile{lof}{\contentsline {figure}{\numberline {4.5}{\ignorespaces Execution times of chains of identity functions}}{38}}
 \newlabel{fig:arrow_chaining_overhead}{{4.5}{38}}
-\@writefile{toc}{\contentsline {chapter}{\numberline {5}Conclusion}{39}}
+\@writefile{toc}{\contentsline {chapter}{\numberline {5}Conclusions}{39}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}
-\@writefile{toc}{\contentsline {section}{\numberline {5.1}Future work}{39}}
-\@writefile{toc}{\contentsline {subsection}{\numberline {5.1.1}Performance enhancements}{39}}
-\newlabel{sec:performance_enhancements}{{5.1.1}{39}}
+\@writefile{toc}{\contentsline {section}{\numberline {5.1}Final words}{40}}
 \@writefile{toc}{\contentsline {chapter}{\numberline {A}Arrow laws}{41}}
 \@writefile{lof}{\addvspace {10\p@ }}
 \@writefile{lot}{\addvspace {10\p@ }}

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)  29 APR 2013 21:15
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  29 APR 2013 22:04
 entering extended mode
 **Dissertation.tex
 
 (pdftex.def)             Requested size: 411.93877pt x 292.66003pt.
  [33 <C:/Users/David/Documents/Visual Studio 2010/Projects/ArrowDataBinding/Dis
 sertation/fig/CaseStudyListBinding.png>]
-[34] [35]
+[34]
+
+LaTeX Warning: Reference `sec:performance_enhancements' on page 35 undefined on
+ input line 753.
+
+[35]
 <fig/SimpleFunctionPerformanceChart.pdf, id=235, 496.44887pt x 258.75552pt>
 File: fig/SimpleFunctionPerformanceChart.pdf Graphic file (type pdf)
 
 [39
 
 
-] [40
-
-]
+] [40]
 Appendix A.
 [41
 
+
 ] [42]
 Appendix B.
 [43
 \pc@column@2=\box30
 \pc@column@width@2=\dimen120
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 979.
+ne 977.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 979.
+ne 977.
 [45
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1034.
+ne 1032.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1034.
+ne 1032.
  [46]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1079.
+ne 1077.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1079.
+ne 1077.
  [47] [48]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1121.
+ne 1119.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1121.
+ne 1119.
  [49
 
 ]
 Package parcolumns Info: Width of column 1 calculated as 194.2195pt on input li
-ne 1163.
+ne 1161.
 Package parcolumns Info: Width of column 2 calculated as 194.2195pt on input li
-ne 1163.
+ne 1161.
  [50]
 ("C:\Users\David\Documents\Visual Studio 2010\Projects\ArrowDataBinding\Dissert
 ation\Dissertation.bbl"
 
 ]) [52]
 ("C:\Users\David\Documents\Visual Studio 2010\Projects\ArrowDataBinding\Dissert
-ation\Dissertation.aux") ) 
+ation\Dissertation.aux")
+
+LaTeX Warning: There were undefined references.
+
+ ) 
 Here is how much of TeX's memory you used:
- 2976 strings out of 494045
- 43778 string characters out of 3148387
- 270622 words of memory out of 3000000
- 6246 multiletter control sequences out of 15000+200000
+ 2978 strings out of 494045
+ 43833 string characters out of 3148387
+ 271622 words of memory out of 3000000
+ 6248 multiletter control sequences out of 15000+200000
  12938 words of font info for 46 fonts, out of 3000000 for 9000
  715 hyphenation exceptions out of 8191
  27i,8n,40p,1429b,1520s stack positions out of 5000i,500n,10000p,200000b,50000s
-<C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfo
-nts/cm/cmbx12.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/c
-mitt10.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmmi10.p
-fb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmmi12.pfb><C:/P
-rogram Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr10.pfb><C:/Program Fi
-les/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr12.pfb><C:/Program Files/MiKTe
-X 2.9/fonts/type1/public/amsfonts/cm/cmr17.pfb><C:/Program Files/MiKTeX 2.9/fon
-ts/type1/public/amsfonts/cm/cmr7.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/p
-ublic/amsfonts/cm/cmr8.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsf
-onts/cm/cmsl12.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/
-cmsy10.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmsy8.pf
-b><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmti12.pfb><C:/Pr
-ogram Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmtt10.pfb><C:/Program Fi
-les/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmtt12.pfb><C:/Program Files/MiKT
-eX 2.9/fonts/type1/public/amsfonts/cm/cmtt8.pfb>
-Output written on Dissertation.pdf (62 pages, 566570 bytes).
+<C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmbx12.pfb><C:/Pr
+ogram Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmitt10.pfb><C:/Program F
+iles/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmmi10.pfb><C:/Program Files/MiK
+TeX 2.9/fonts/type1/public/amsfonts/cm/cmmi12.pfb><C:/Program Files/MiKTeX 2.9/
+fonts/type1/public/amsfonts/cm/cmr10.pfb><C:/Program Files/MiKTeX 2.9/fonts/typ
+e1/public/amsfonts/cm/cmr12.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public
+/amsfonts/cm/cmr17.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts
+/cm/cmr7.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmr8.p
+fb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmsl12.pfb><C:/P
+rogram Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmsy10.pfb><C:/Program F
+iles/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmsy8.pfb><C:/Program Files/MiKT
+eX 2.9/fonts/type1/public/amsfonts/cm/cmti12.pfb><C:/Program Files/MiKTeX 2.9/f
+onts/type1/public/amsfonts/cm/cmtt10.pfb><C:/Program Files/MiKTeX 2.9/fonts/typ
+e1/public/amsfonts/cm/cmtt12.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/publi
+c/amsfonts/cm/cmtt8.pfb>
+Output written on Dissertation.pdf (62 pages, 568993 bytes).
 PDF statistics:
  619 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

 
 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}
+\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.
 
 
 A slightly inconvenient (if sensible) feature of C$\sharp$ is the restriction that, unlike in many other similar languages, all methods have to be called on an object or class. Whilst in Java one could import all static methods from a class and use them as though they were defined locally, in C$\sharp$ they need to be prefixed with the class name (i.e. \texttt{StaticClass.Method()}). This of course presented a slight obstacle to making arrow code concise, as chains of operators would build up into messy expressions like \texttt{Combinators.And(Combinators.Arr(f1), Combinators.First(Combinators.Arr(f2)))}. By writing all combinators to be usable as extension methods, writing utility extension methods for \texttt{Func} objects (like \texttt{Func.Arr()} to make a \texttt{Func} into an arrow) and giving the class a short name for the worst case, I was able to keep this to a minimum and so keep combinator-heavy code relatively clean. The \texttt{Op.Combinator()} syntax is still fairly clumsy, but in many cases there was no easy way around this.
 
-\subsubsection{Comparison with Haskell}
+\subsubsection{Comparison with Haskell} \label{sec:syntax_comparison_haskell}
 
 While the syntax is certainly quite concise as C$\sharp$ allows, it certainly doesn't compare to Haskell for a number of reasons. However, this is of course due to a fundamental difference between the languages.
 
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 % Conclusion
 
-\chapter{Conclusion}
+\chapter{Conclusions}
 
-Conclusion goes here!
+As modular architectures like MVC and MVVM grow ever more popular, data binding will continue to be important in bridging the gap between disconnected sections of code. This project has been an exploration of a more functional approach to the problem which I think could work very well in future, as functional ideas like lambda expressions and type inference are rapidly becoming mainstream tools in software development. Overall I consider it a success, as despite a few syntactic issues it ultimately fulfils all I set out to do and performs reasonably well. Nonetheless, there are still several additions I may make in future to improve the framework:
 
-\section{Future work}
-
-\begin{itemize}
-	\item Performance issues - optimisations possible with dynamic expression trees?
-	\item Messiness caused by use of Tuples - would be better with a custom tree type?
-	\item Feedback arrows
-	\item Better integration with WPF
-	\item Syntax enhancements, perhaps through Roslyn
-\end{itemize}
+\begin{description}
+	\item[Custom tuple type] The C$\sharp$ \texttt{Tuple} type, whilst very helpful initially, led to a lot of complications with many-to-many bindings (explored in Section \ref{sec:many_many_bindings}). This could have been avoided had I created my own binary-tree-structured type designed to be easily usable with the binding framework, and I could even implement conversion from standard tuples easily enough.
+	\item[Better integration with WPF] Unfortunately I was unable to completely integrate the arrows with WPF to the point where they can be used in XAML. This issue was explored and found to be very difficult to work around, so is best left to future work.
+	\item[Feedback arrows] Haskell's arrows provide some fairly useful looping functionality through arrow feedback, but due to time constraints (and to avoid scope creep) this was not fully explored. However, this would perhaps be an interesting thing to look into in future.
+	\item[Syntax enhancements] As mentioned at the end of Section \ref{sec:syntax_comparison_haskell}, Roslyn could perhaps be used to develop a more Haskell-like syntax for arrows. However, this would likely be very complicated and would need to be postponed until Roslyn is complete.
+	\item[Performance] Arrow performance is still not ideal: chaining together arrows with the combinators adds a lot of overhead as the complexity increases. A possible improvement would be to look at using C$\sharp$ \texttt{ExpressionTree} manipulations to dynamically simplify the results of arrow combinations.
+\end{description}
 
-\subsection{Performance enhancements} \label{sec:performance_enhancements}
+\section{Final words}
 
-Blah
+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 built around it. 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. 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.
 
 \cleardoublepage
 

File Dissertation/Dissertation.toc

 \contentsline {subsubsection}{Simple function results}{35}
 \contentsline {subsubsection}{List function results}{36}
 \contentsline {subsubsection}{Overhead due to arrow chaining}{37}
-\contentsline {chapter}{\numberline {5}Conclusion}{39}
-\contentsline {section}{\numberline {5.1}Future work}{39}
-\contentsline {subsection}{\numberline {5.1.1}Performance enhancements}{39}
+\contentsline {chapter}{\numberline {5}Conclusions}{39}
+\contentsline {section}{\numberline {5.1}Final words}{40}
 \contentsline {chapter}{\numberline {A}Arrow laws}{41}
 \contentsline {section}{\numberline {A.1}Normal arrow laws}{41}
 \contentsline {section}{\numberline {A.2}Invertible arrow laws}{42}