\chapter{Prototype}
  An important step in this research is the creation of a prototype compiler.
  Having this prototype allows us to apply the ideas from the previous chapter
  to actual hardware descriptions and evaluate their usefulness. Having a
  prototype also helps to find new techniques and test possible
  interpretations.

  Obviously the prototype was not created after all research
  ideas were formed, but its implementation has been interleaved with the
  research itself. Also, the prototype described here is the final version, it
  has gone through a number of design iterations which we will not completely
  describe here.

  \section{Choice of language}
    When implementing this prototype, the first question to ask is: What
    (functional) language will we use to describe our hardware? (Note that
    this does not concern the \emph{implementation language} of the compiler,
    just the language \emph{translated by} the compiler).

    On the highest level, we have two choices:

    \startitemize
      \item Create a new functional language from scratch. This has the
      advantage of having a language that contains exactly those elements that
      are convenient for describing hardware and can contain special
      constructs that might.
      \item Use an existing language and create a new backend for it. This has
      the advantage that existing tools can be reused, which will speed up
      development.
    \stopitemize

    Considering that we required a prototype which should be working quickly,
    and that implementing parsers, semantic checkers and especially
    typcheckers isn't exactly the core of this research (but it is lots and
    lots of work!), using an existing language is the obvious choice. This
    also has the advantage that a large set of language features is available
    to experiment with and it is easy to find which features apply well and
    which don't. A possible second prototype could use a custom language with
    just the useful features (and possibly extra features that are specific to
    the domain of hardware description as well).

    The second choice is to pick one of the many existing languages. As
    mentioned before, this language is Haskell.  This choice has not been the
    result of a thorough comparison of languages, for the simple reason that
    the requirements on the language were completely unclear at the start of
    this language. The fact that Haskell is a language with a broad spectrum
    of features, that it is commonly used in research projects and that the
    primary compiler, GHC, provides a high level API to its internals, made
    Haskell an obvious choice.

    TODO: Was Haskell really a good choice? Perhaps say this somewhere else?

  \section{Prototype design}
    As stated above, we will use the Glasgow Haskell Compiler (\small{GHC}) to
    implement our prototype compiler. To understand the design of the
    compiler, we will first dive into the \small{GHC} compiler a bit. It's
    compilation consists of the following steps (slightly simplified):

    \startdesc{Frontend}
      This step takes the Haskell source files and parses them into an
      abstract syntax tree (\small{AST}). This \small{AST} can express the
      complete Haskell language and is thus a very complex one (in contrast
      with the Core \small{AST}, later on). All identifiers in this
      \small{AST} are resolved by the renamer and all types are checked by the
      typechecker.
    \stopdesc
    \startdesc{Desugaring}
      This steps takes the full \small{AST} and translates it to the
      \emph{Core} language. Core is a very small functional language with lazy
      semantics, that can still express everything Haskell can express. Its
      simpleness makes Core very suitable for further simplification and
      translation. Core is the language we will be working on as well.
    \stopdesc
    \startdesc{Simplification}
      Through a number of simplification steps (such as inlining, common
      subexpression elimination, etc.) the Core program is simplified to make
      it faster or easier to process further.
    \stopdesc
    \startdesc{Backend}
      This step takes the simplified Core program and generates an actual
      runnable program for it. This is a big and complicated step we will not
      discuss it any further, since it is not required for our prototype.
    \stopdesc

        Core - description of the language (appendix?)
	Stages (-> Core, Normalization, -> VHDL)
        Implementation issues

        Haskell language coverage / constraints
                Recursion
                Builtin types
                Custom types (Sum types, product types)
                Function types / higher order expressions

