\chapter[chap:context]{Context}
  An obvious question that arises when starting any research is \quote{Has
  this not been done before?} Using a functional language for describing hardware
  is not a new idea at all. In fact, there has been research into functional
  hardware description even before the conventional hardware description
  languages were created. \todo{Reference about early FHDLs} However,
  functional languages were not nearly as advanced as they are now, and
  functional hardware description never really got off. 

\todo{Add references}
  Recently, there have been some renewed efforts, especially using the Haskell
  functional language. Examples are Lava, ForSyde, ..., which are all a form of an
  embedded domain specific language. Each of these have a slightly different
  approach, but all of these do some trickery inside the Haskell language
  itself, meaning you write a program that generates a hardware circuit,
  instead of describing the circuit directly (either by running the haskell
  code after compilation, or using Template Haskell to inspect parts of the
  code you have written). This allows the full power of Haskell for generating
  a circuit. However it also creates severe limitations in the use of the
  language (you can't use case expressions in Lava, since they would be
  executed only once during circuit generation) and extra notational overhead.

  We will now have a look at the existing hardware description languages,
  both conventional and functional to see the fields in which Cλash is
  operating.

  \section{Conventional hardware description languages}
    Considering that we already have some hardware description languages like
    \small{VHDL} and Verilog, why would we need anything else? By introducing
    the functional style to hardware description, we hope to obtain a hardware
    description language that is:
    \startitemize
      \item More consise. Functional programs are known for their conciseness
      and ability to abstract away  common patterns.  This is largely enabled
      by features like an advanced type system with polymorphism and higher
      order functions.
      \item Type-safer. Functional programs typically have a highly expressive
      type system, which makes it harder to write incorrect code.
      \item Easy to process. Functional languages have nice properties like
      purity \refdef{purity} and single binding behaviour, which make it easy
      to apply program transformations and optimizations and could potentially
      simplify program verification.
    \stopitemize
  
    \placeintermezzo{}{
      \defref{EDSL}
      \startframedtext[width=8.5cm,background=box,frame=no]
      \startalignment[center]
        {\tfa Embedded domain-specific languages (\small{EDSL})}
      \stopalignment
      \blank[medium]
     
      \startcitedquotation[deursen00]
      A domain-specific language (\small{DSL}) is a program-
      ming language or executable specification language
      that offers, through appropriate notations and ab-
      stractions, expressive power focused on, and usu-
      ally restricted to, a particular problem domain.
      \stopcitedquotation

      An embedded \small{DSL} is a \small{DSL} that is embedded in
      another language. Haskell is commonly used to embed \small{DSL}s
      in, which typically means a number of Haskell functions and types
      are made available that can be called to construct a large value
      of some domain-specific datatype (\eg, a circuit datatype). This
      generated datatype can then be processed further by the
      \small{EDSL} \quote{compiler} (which runs in the same environment
      as the \small{EDSL} itself. The embedded language is then a, mostly
      applicative, subset of Haskell where the library functions are the
      primitives. Sometimes advanced haskell features such as
      polymorphism, higher order values or type classes can be used in
      the embedded language. \cite[hudak96]
      \stopframedtext
    }

  \section[sec:context:fhdls]{Existing functional hardware description languages}
    As noted above, we're not the first to walk this path. However, current
    embedded functional hardware description languages (in particular those
    using Haskell) are limited by:\todo{Separate TH and EDSL approaches
    better}
    \startitemize
      \item Not all of Haskell's constructs can be captured by embedded domain
      specific languages. For example, an if or case expression is typically
      executed only once and only its result is reflected in the embedded
      description, not the if or case expression itself. Also, sharing of
      variables (\eg, using the same variable twice while only calculating it
      once) and cycles in circuits are non-trivial to properly and safely
      translate (though there is some work to fix this, but that has not been
      possible in a completely reliable way yet. \cite[gill09]
      \item Some things are verbose to express. Especially ForSyDe suffers
      from a lot of notational overhead due to the Template Haskell approach
      used. Since conditional expressions are not supported, a lot of Haskell's
      syntax sugar (if expressions, pattern matching, guards) cannot be used
      either, leading to more verbose notation as well.
      \item Polymorphism and higher order values are not supported within the
      embedded language. The use of Haskell as a host language allows the use
      of polymorphism and higher order functions at circuit generation time
      (even for free, without any additional cost on the \small{EDSL}
      programmers), but the described circuits do not have any polymorphism
      or higher order functions, which can be limiting. \todo{How true or
      appropriate is this point?}
      \todo[left]{Function structure gets lost (in Lava)}
    \stopitemize

    \todo[text]{Complete translation in TH is complex: Works with Haskell AST
    instead of Core}

% vim: set sw=2 sts=2 expandtab:
