Commits

David Barker committed ee87440

Finished off the requirements analysis section

  • Participants
  • Parent commits 4c5d541

Comments (0)

Files changed (4)

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 MAR 2013 18:30
+This is pdfTeX, Version 3.1415926-2.3-1.40.12 (MiKTeX 2.9 64-bit) (preloaded format=pdflatex 2012.10.5)  29 MAR 2013 18:40
 entering extended mode
 **Dissertation.tex
 
 Chapter 2.
 [5
 
-] [6] [7] [8
-
-]
+] [6] [7] [8]
 Chapter 3.
 [9
 
+
 ] ("C:\Program Files\MiKTeX 2.9\tex\latex\listings\lstlang1.sty"
 File: lstlang1.sty 2004/09/05 1.3 listings language file
 )
 nts/cm/cmsy10.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/c
 mti12.pfb><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmtt10.pf
 b><C:/Program Files/MiKTeX 2.9/fonts/type1/public/amsfonts/cm/cmtt12.pfb>
-Output written on Dissertation.pdf (44 pages, 399346 bytes).
+Output written on Dissertation.pdf (44 pages, 399920 bytes).
 PDF statistics:
  524 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

 
 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.
 
-Exploring existing libraries highlighted a couple of extra features which I had not previously thought would be necessary: arbitrary many-to-many bindings, which are useful in a variety of situations, and list bindings. The latter refers to the situation where the data source is actually a list of data, and would have been possible with normal arrows. However, it would have been fairly messy to do, and simple tasks like filtering and mapping would have required large loops. Given list binding is done fairly often in reality, I decided it would make sense to add an arrow type for handling them and a variety of list processing methods.
+Exploring existing libraries highlighted a couple of extra features which I had not previously thought would be necessary: arbitrary many-to-many bindings, which are useful in a variety of situations, and list bindings. The latter refers to the situation where the data source is actually a list of data, and would have been possible with normal arrows. However, it would have been fairly messy to do, and simple tasks like filtering and mapping would have required large loops. Given list binding is done fairly often in practice, I decided it would make sense to add an arrow type for handling them and a variety of list processing methods.
 
-[Arrow requirements...]
+For the arrows, the requirements were taken from the existing, successful implementation in Haskell. Essentially, I sought to implement all the main combinators and make the syntax as clear as possible. The main obstacle to keeping the syntax clean was the type system, and so much of the preparation time for arrows was spent devising the best approach for minimising type parameters and making the operators compatible. This stage of the project is described in greater detail in Section \ref{sec:arrows_overview}.
 
 \section{Software engineering approach}