<commit_before>\chapter{Previous Implementations}
  Since Fran was first announced there have been several further implementations of FRP's semantics. Here
  we will explore a selection of these, focusing on work carried out in both Haskell and Scala.
  
  \section{Haskell}
    Much of the FRP community could be described as a subset of the Haskell community due to FRP's
    origins and sensibilities. It's not surprising that there have been several major implementations
    of FRP in the language. Here we will explore two of the most prominent.
    
    \subsection{Reactive}
      Reactive was developed as a research project by <NAME> and was the feature
      of the paper ``Push-Pull Functional Reactive Programming'' \cite{Elliott2009}. As mentioned
      in section 2 this paper dealt with clarifying and restructuring the Behaviour and Events
      to promote more efficient implementations without altering the overall semantic model.
      
      Reactive introduces a new type that can be used to simplify what he referred to as
      `reactive' values (such as lifted static values and \emph{stepper} Behaviours):
    
\begin{verbatim}
type Reactive[T] = Stream[(Time, T)]
\end{verbatim}

      We can think of Behaviours in a similar manner as a Behaviour is
      a Stream of Time =$>$ T functions:
      
\begin{verbatim}
type Behaviour[T] = Reactive[Time => T]
\end{verbatim}      

      In other words a Behaviour is simply a stream of `phases' that exist between discrete
      points in time (think of the \emph{switcher} operation in section 2). Of course, we
      still think of a Behaviour's value at a sample time as the result of evaluating a
      Time =$>$ T function but this representation
      does provide a clearer definition of Behaviours used reactively with Events.
      
      As one might expect from a framework created by Elliott, Reactive has all the other major features
      of Fran: Events and \emph{switcher} etc. However, Reactive was mainly intended as an experiment
      and as such hasn't been utilised in many cases and is reportedly not altogether stable.
  
    \subsection{Reactive-Banana}
      `Reactive-Banana' is a Haskell FRP framework created by <NAME> \cite{Apfelmus}. Reactive-Banana
      is directly based on the on the FRP defined in Functional Reactive Animation \cite{Elliott1997}. Apfelmus
      implements Events in manner representing the original semantics but chooses to alter
      Behaviours somewhat. 
      
      Reactive-Banana uses a form of Behaviour equivalent to the \emph{stepper}
      (also similar to the Reactive type discussed above) operation seen in section 2. This simplification of Behaviours allows 
      Apfelmus to use a push
      based implementation where Behaviours don't need polling to keep output components (UI etc) up to date as changes in their values are exposed
      by Events occurring. While this may be more efficient \footnote{The fact that Behaviours must polled is not really an inefficiency as it is required due to their continuous nature. } it excludes the ability to create truly 
      continuous Behaviours and therefore Reactive-Banana does not really provide a true implementation
      of Behaviours. This seems like a strange decision. Optimising `constant' Behaviours would be sensible
      but removing continuous Behaviours altogether removes the ability to create abstractions that programmers
      might be willing to except a performance drop for.
      
      Apfelmus' framework also drops some functionality from FRP in the form of the \emph{switcher} function as
      he argues that in some cases it requires storing the entire history of an Event (as discussed previously
      in section 2).
      
    It should be noted that both Reactive and Reactive-banana do not expose an \emph{at} or \emph{occs} function
    and treat Behaviours and Events as real-time changing values (with respect to the current time). They also both do not 
    retain Event 
    occurrences infinitely: only the last occurrence at any point in time is stored. Similar decisions are made in the 
    implementation of Echo and the consequences and advantages of these will be discussed later.

  \section{Scala}
    As one might imagine, there has also been previous work in implementing FRP in Scala. 

    \subsection{Reactive}
      Arguably the most significant of the FRP work in Scala is the library `reactive' created by `nafg' \cite{Nafg}. This    
      framework was designed to allow for the creation of functional reactive web applications however here we are concerned 
      with the basic FRP library `reactive-core'. Unfortunately while claiming to be an FRP library `Reactive'
      has a couple of problems.

      The framework is based around two types designed to represent Behaviours and Events respectively: Signals
      and EventStreams. EventStreams are very close to the original Event semantics but Signal deviates quite significantly 
      from Behaviour's. Signal is defined as follows:

      \begin{quote}
        In practical terms, a Signal has a current value, and an EventStream that, whenever the Signal's value changes,     
        fires the new value.
      \end{quote}  
      
      It can be seen that, as with `Reactive-Banana', this is just optimised implementation of the \emph{stepper}
      operation.

    \subsection{React}
      While not claiming to be an implementation of FRP the `React' framework proposed in the 
      paper `Deprecating the Observer Pattern' \cite{Maier2010} does utilise a notion of Events that, as cited in the paper,
      has its routes in FRP.

      The Event's in React are very similar to the Events in Fran \cite{Elliott1997}: they are conceptually infinite
      and have the \emph{merge} and \emph{map} operations defined on them. One slight difference is that React's
      Events expose an operation to allow them to `occur' with a public \emph{emit} function. This disrupts
      the abstraction of Events somewhat. For instance, if we have again have a \emph{mouseB} Event we could do the following:

\begin{verbatim}
val event = mouseB
event.emit(())
\end{verbatim}      

      Here we cause the mouse button Event to occur without the actual input occurring. It will be shown later how to     
      internalise this action effectively so as to maintain the abstraction. 

      Interestingly, React also contains a notion of Signals, just as Reactive does, 
      however it doesn't claim that these are an implementation of Behaviours (although the word `continuous' is
      used loosely in their description). 
      
      As with the Haskell frameworks, the implementation of Reactive does not retain Event occurrences before the
      last one. The source code for React is not currently available Event implementation in the framework is unclear
      however the functionality never implies that Events would need to retain old data.
      
\section{Comparison}
  We can compare these frameworks with respect to the presence of various key features. These are Behaviours, Events, 
  \emph{stepper} - discretely 
  changing value and \emph{switcher} - continuous value that switches to other continuous values at discrete points in time.
  
  \begin{center}
     \begin{tabular}{ | l | l | l | l | l | }
       \hline
        & Reactive (Haskell) & Reactive-Banana & Reactive (Scala) & React \\ \hline \hline
       Behaviours & Yes & No & No & No \\ \hline
       Events & Yes & Yes & Yes & Yes \\ \hline
       \emph{stepper} & Yes & Yes & Yes & Yes \\ \hline
       \emph{switcher} & Yes & No & No & No \\ \hline  
       \hline
     \end{tabular}
   \end{center}
   
   It can be seen that purely continuous Behaviours are often not implemented for whatever reason
   but the \emph{stepper} version
   of them often is (it can be seen that this version is very useful in Appendix A and B). In this report it will
   be shown that it is possible to implement all of these features in Scala without having to use unbounded levels
   of memory for Events.<commit_msg>Refactor some judgement. Still not happy with previous section<commit_after>\chapter{Previous Implementations}
  Since Fran was first announced there have been several further implementations of FRP's semantics. Here
  we will explore a selection of these, focusing on work carried out in both Haskell and Scala.
  
  \section{Haskell}
    Much of the FRP community could be described as a subset of the Haskell community due to FRP's
    origins and sensibilities. It's not surprising that there have been several major implementations
    of FRP in the language therefore. Here we will explore two of the most prominent.
    
    \subsection{Reactive}
      Reactive was developed as a research project by <NAME> and was the feature
      of the paper ``Push-Pull Functional Reactive Programming'' \cite{Elliott2009}. As mentioned
      in section 2 this paper dealt with clarifying and restructuring the denotational
      semantics of FRP
      to promote more efficient implementations without altering the overall semantic model.
      
      Reactive introduces a new type that can be used to simplify what he referred to as
      `reactive' values (such as lifted static values and \emph{stepper} Behaviours):
    
\begin{verbatim}
type Reactive[T] = Stream[(Time, T)]
\end{verbatim}

      Elliott also presents a way to express Behaviours using this new type:
      
\begin{verbatim}
type Behaviour[T] = Reactive[Time => T]
\end{verbatim}      

      In other words a Behaviour is simply a stream of `phases' that exist between discrete
      points in time (think of the \emph{switcher} operation in section 2). Of course, we
      still think of a Behaviour's value at a sample time as the result of evaluating a
      Time =$>$ T function but using the Reactive type
      does provide a clearer definition of Behaviours used reactively with Events.
      
      As one might expect from a framework created by Elliott, Reactive has all the other major features
      of Fran: Events and \emph{switcher} etc. However, Reactive was mainly intended as an experiment
      and as such hasn't been utilised in many cases and is reportedly not altogether stable.
  
    \subsection{Reactive-Banana}
      `Reactive-Banana' is a Haskell FRP framework created by <NAME> \cite{Apfelmus}. Reactive-Banana
      is directly based on the on the FRP defined in Functional Reactive Animation \cite{Elliott1997}. Apfelmus
      implements Events in manner representing the original semantics but chooses to alter
      Behaviours somewhat. 
      
      Reactive-Banana uses a form of Behaviour equivalent to the \emph{stepper}
      (also similar to the Reactive type discussed above) operation seen in section 2. This simplification of Behaviours allows 
      Apfelmus to use a push
      based implementation where Behaviours don't need polling to keep output components (UI etc) up to date as changes in their values are exposed
      by Events occurring. While this may be more efficient \footnote{The fact that Behaviours must polled is not really an inefficiency as it is required due to their continuous nature. } it excludes the ability to create truly 
      continuous Behaviours and therefore Reactive-Banana does not really provide a true implementation
      of Behaviours. This seems like a strange decision. Optimising `constant' Behaviours is sensible
      but removing continuous Behaviours entirely removes the ability to create abstractions that may present
      an acceptable loss in performance to the programmer.
      
      Apfelmus' framework also drops some functionality from FRP in the form of the \emph{switcher} function as
      he argues that in some cases it requires storing the entire history of an Event (as discussed previously
      in section 2).
      
    It should be noted that both Reactive and Reactive-banana do not expose an \emph{at} or \emph{occs} function
    and treat Behaviours and Events as real-time changing values (with respect to the current time). They also both do not 
    retain Event 
    occurrences infinitely: only the last occurrence at any point in time is stored. Similar decisions are made in the 
    implementation of Echo and the consequences and advantages of these will be discussed later.

  \section{Scala}
    As one might imagine, there has also been previous work in implementing FRP in Scala. 

    \subsection{Reactive}
      Arguably the most significant of the FRP work in Scala is the library `reactive' created by `nafg' \cite{Nafg}. This    
      framework was designed to allow for the creation of functional reactive web applications however here we are concerned 
      with the basic FRP library `reactive-core'. Unfortunately while claiming to be an FRP library `Reactive'
      has a couple of problems.

      The framework is based around two types designed to represent Behaviours and Events respectively: Signals
      and EventStreams. EventStreams are very close to the original Event semantics but Signal deviates quite significantly 
      from Behaviour's. Signal is defined as follows:

      \begin{quote}
        In practical terms, a Signal has a current value, and an EventStream that, whenever the Signal's value changes,     
        fires the new value.
      \end{quote}  
      
      It can be seen that, as with `Reactive-Banana', this is just optimised implementation of the \emph{stepper}
      operation.

    \subsection{React}
      While not claiming to be an implementation of FRP the `React' framework proposed in the 
      paper `Deprecating the Observer Pattern' \cite{Maier2010} does utilise a notion of Events that, as cited in the paper,
      has its routes in FRP.

      The Event's in React are very similar to the Events in Fran \cite{Elliott1997}: they are conceptually infinite
      and have the \emph{merge} and \emph{map} operations defined on them. One slight difference is that React's
      Events expose an operation to allow them to `occur' with a public \emph{emit} function. This disrupts
      the abstraction of Events somewhat. For instance, if we have again have a \emph{mouseB} Event we could do the following:

\begin{verbatim}
val event = mouseB
event.emit(())
\end{verbatim}      

      Here we cause the mouse button Event to occur without the actual input occurring. It will be shown later how to     
      internalise this action effectively so as to maintain the abstraction. 

      Interestingly, React also contains a notion of Signals, just as Reactive does, 
      however it doesn't claim that these are an implementation of Behaviours (although the word `continuous' is
      used loosely in their description). 
      
      As with the Haskell frameworks, the implementation of Reactive does not retain Event occurrences before the
      last one. The source code for React is not currently available Event implementation in the framework is unclear
      however the functionality never implies that Events would need to retain old data.
      
\section{Comparison}
  We can compare these frameworks with respect to the presence of various key features. These are Behaviours, Events, 
  \emph{stepper} - discretely 
  changing value and \emph{switcher} - continuous value that switches to other continuous values at discrete points in time.
  
  \begin{center}
     \begin{tabular}{ | l | l | l | l | l | }
       \hline
        & Reactive (Haskell) & Reactive-Banana & Reactive (Scala) & React \\ \hline \hline
       Behaviours & Yes & No & No & No \\ \hline
       Events & Yes & Yes & Yes & Yes \\ \hline
       \emph{stepper} & Yes & Yes & Yes & Yes \\ \hline
       \emph{switcher} & Yes & No & No & No \\ \hline  
       \hline
     \end{tabular}
   \end{center}
   
   It can be seen that purely continuous Behaviours are often not implemented for whatever reason
   but the \emph{stepper} version
   of them often is (it can be seen that this version is very useful in Appendix A and B). In this report it will
   be shown that it is possible to implement all of these features in Scala without having to use unbounded levels
   of memory for Events.
{'fraction_non_alphanumeric': 0.04442664366257933, 'fraction_numerical': 0.002464723642861544, 'mean_word_length': 3.2144897429239156, 'pattern_counts': {'":': 0, '<': 7, '<?xml version=': 0, '>': 12, 'https://': 0, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 2, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '215663', 'n_tokens_mistral': 4173, 'n_tokens_neox': 3911, 'n_words': 2223}