TODO: Was Haskell really a good choice? Perhaps say this somewhere else?
- \subsection[sec:prototype:output]{Output format}
+ \section[sec:prototype:output]{Output format}
The second important question is: What will be our output format? Since
our prototype won't be able to program FPGA's directly, we'll have to have
output our hardware in some format that can be later processed and
Each Core expression consists of one of these possible expressions.
\startdesc{Variable reference}
-\startlambda
-a
-\stoplambda
+ \startlambda
+ a
+ \stoplambda
This is a simple reference to a binder. It's written down as the
name of the binder that is being referred to, which should of course be
bound in a containing scope (including top level scope, so a reference
cast expressions. This minimize the amount of bookkeeping needed to keep
the typing consistent.
\stopdesc
+
\startdesc{Literal}
-\startlambda
-10
-\stoplambda
+ \startlambda
+ 10
+ \stoplambda
This is a simple literal. Only primitive types are supported, like
chars, strings, ints and doubles. The types of these literals are the
\quote{primitive} versions, like \lam{Char\#} and \lam{Word\#}, not the
normal Haskell versions (but there are builtin conversion functions).
\stopdesc
+
\startdesc{Application}
-\startlambda
-func arg
-\stoplambda
+ \startlambda
+ func arg
+ \stoplambda
This is simple function application. Each application consists of two
parts: The function part and the argument part. Applications are used
for normal function \quote{calls}, but also for applying type
The value of an application is the value of the function part, with the
first argument binder bound to the argument part.
\stopdesc
+
\startdesc{Lambda abstraction}
-\startlambda
-λbndr.body
-\stoplambda
+ \startlambda
+ λbndr.body
+ \stoplambda
This is the basic lambda abstraction, as it occurs in labmda calculus.
It consists of a binder part and a body part. A lambda abstraction
- creates a function, that can be applied to an argument.
+ creates a function, that can be applied to an argument. The binder is
+ usually a value binder, but it can also be a \emph{type binder} (or
+ \emph{type variable}). The latter case introduces a new polymorphic
+ variable, which can be used in types later on. See
+ \in{section}[sec:prototype:coretypes] for details.
Note that the body of a lambda abstraction extends all the way to the
end of the expression, or the closing bracket surrounding the lambda. In
The value of an application is the value of the body part, with the
binder bound to the value the entire lambda abstraction is applied to.
\stopdesc
+
\startdesc{Non-recursive let expression}
-\startlambda
-let bndr = value in body
-\stoplambda
+ \startlambda
+ let bndr = value in body
+ \stoplambda
A let expression allows you to bind a binder to some value, while
evaluating to some other value (where that binder is in scope). This
allows for sharing of subexpressions (you can use a binder twice) and
calculus, it is easily translated to a lambda abstraction. The let
expression above would then become:
-\startlambda
-(λbndr.body) value
-\stoplambda
+ \startlambda
+ (λbndr.body) value
+ \stoplambda
This notion might be useful for verifying certain properties on
transformations, since a lot of verification work has been done on
The value of a let expression is the value of the body part, with the
binder bound to the value.
\stopdesc
- \startdesc{Recursive let expression}
-\startlambda
-letrec
- bndr1 = value1
- \vdots
- bndrn = valuen
-in
- body
-\stoplambda
+ \startdesc{Recursive let expression}
+ \startlambda
+ letrec
+ bndr1 = value1
+ \vdots
+ bndrn = valuen
+ in
+ body
+ \stoplambda
This is the recursive version of the let expression. In \small{GHC}'s
Core implementation, non-recursive and recursive lets are not so
distinct as we present them here, but this provides a clearer overview.
lambda calculus, if we use the \emph{least fixed-point operator},
\lam{Y}.
\stopdesc
+
\startdesc{Case expression}
-\startlambda
- case scrut of bndr
- DEFAULT -> defaultbody
- C0 bndr0,0 ... bndr0,m -> body0
- \vdots
- Cn bndrn,0 ... bndrn,m -> bodyn
-\stoplambda
-
-TODO: Define WHNF
-
- A case expression is the only way in Core to choose between values. A case
- expression evaluates its scrutinee, which should have an algebraic
- datatype, into weak head normal form (\small{WHNF}) and (optionally) binds
- it to \lam{bndr}. It then chooses a body depending on the constructor of
- its scrutinee. If none of the constructors match, the \lam{DEFAULT}
- alternative is chosen.
-
- Since we can only match the top level constructor, there can be no overlap
- in the alternatives and thus order of alternatives is not relevant (though
- the \lam{DEFAULT} alternative must appear first for implementation
- efficiency).
-
- Any arguments to the constructor in the scrutinee are bound to each of the
- binders after the constructor and are in scope only in the corresponding
- body.
-
- To support strictness, the scrutinee is always evaluated into WHNF, even
- when there is only a \lam{DEFAULT} alternative. This allows a strict
- function argument to be written like:
-
-\startlambda
-function (case argument of arg
- DEFAULT -> arg)
-\stoplambda
-
- This seems to be the only use for the extra binder to which the scrutinee
- is bound. When not using strictness annotations (which is rather pointless
- in hardware descriptions), \small{GHC} seems to never generate any code
- making use of this binder. The current prototype does not handle it
- either, which probably means that code using it would break.
-
- Note that these case statements are less powerful than the full Haskell
- case statements. In particular, they do not support complex patterns like
- in Haskell. Only the constructor of an expression can be matched, complex
- patterns are implemented using multiple nested case expressions.
-
- Case statements are also used for unpacking of algebraic datatypes, even
- when there is only a single constructor. For examples, to add the elements
- of a tuple, the following Core is generated:
-
-\startlambda
-sum = λtuple.case tuple of
- (,) a b -> a + b
-\stoplambda
-
- Here, there is only a single alternative (but no \lam{DEFAULT}
- alternative, since the single alternative is already exhaustive). When
- it's body is evaluated, the arguments to the tuple constructor \lam{(,)}
- (\eg, the elements of the tuple) are bound to \lam{a} and \lam{b}.
- \stopdesc
- \startdesc{Cast expression}
-\startlambda
-body :: targettype
-\stoplambda
- A cast expression allows you to change the type of an expression to an
- equivalent type. Note that this is not meant to do any actual work, like
- conversion of data from one format to another, or force a complete type
- change. Instead, it is meant to change between different representations
- of the same type, \eg switch between types that are provably equal (but
- look different).
-
- In our hardware descriptions, we typically see casts to change between a
- Haskell newtype and its contained type, since those are effectively
- different representations of the same type.
-
- More complex are types that are proven to be equal by the typechecker,
- but look different at first glance. To ensure that, once the typechecker
- has proven equality, this information sticks around, explicit casts are
- added. In our notation we only write the target type, but in reality a
- cast expressions carries around a \emph{coercion}, which can be seen as a
- proof of equality. TODO: Example
-
- The value of a cast is the value of its body, unchanged. The type of this
- value is equal to the target type, not the type of its body.
-
- Note that this syntax is also used sometimes to indicate that a particular
- expression has a particular type, even when no cast expression is
- involved. This is then purely informational, since the only elements that
- are explicitely typed in the Core language are the binder references and
- cast expressions, the types of all other elements are determined at
- runtime.
- \stopdesc
- \startdesc{Note}
-
- The Core language in \small{GHC} allows adding \emph{notes}, which serve
- as hints to the inliner or add custom (string) annotations to a core
- expression. These shouldn't be generated normally, so these are not
- handled in any way in the prototype.
- \stopdesc
- \startdesc{Type}
-\startlambda
-@type
-\stoplambda
- It is possibly to use a Core type as a Core expression. This is done to
- allow for type abstractions and applications to be handled as normal
- lambda abstractions and applications above. This means that a type
- expression in Core can only ever occur in the argument position of an
- application, and only if the type of the function that is applied to
- expects a type as the first argument. This happens for all polymorphic
- functions, for example, the \lam{fst} function:
-
-\startlambda
-fst :: \forall a. \forall b. (a, b) -> a
-fst = λtup.case tup of (,) a b -> a
-
-fstint :: (Int, Int) -> Int
-fstint = λa.λb.fst @Int @Int a b
-\stoplambda
+ \startlambda
+ case scrut of bndr
+ DEFAULT -> defaultbody
+ C0 bndr0,0 ... bndr0,m -> body0
+ \vdots
+ Cn bndrn,0 ... bndrn,m -> bodyn
+ \stoplambda
+
+ TODO: Define WHNF
+
+ A case expression is the only way in Core to choose between values. A case
+ expression evaluates its scrutinee, which should have an algebraic
+ datatype, into weak head normal form (\small{WHNF}) and (optionally) binds
+ it to \lam{bndr}. It then chooses a body depending on the constructor of
+ its scrutinee. If none of the constructors match, the \lam{DEFAULT}
+ alternative is chosen.
+
+ Since we can only match the top level constructor, there can be no overlap
+ in the alternatives and thus order of alternatives is not relevant (though
+ the \lam{DEFAULT} alternative must appear first for implementation
+ efficiency).
+
+ Any arguments to the constructor in the scrutinee are bound to each of the
+ binders after the constructor and are in scope only in the corresponding
+ body.
+
+ To support strictness, the scrutinee is always evaluated into WHNF, even
+ when there is only a \lam{DEFAULT} alternative. This allows a strict
+ function argument to be written like:
+
+ \startlambda
+ function (case argument of arg
+ DEFAULT -> arg)
+ \stoplambda
+
+ This seems to be the only use for the extra binder to which the scrutinee
+ is bound. When not using strictness annotations (which is rather pointless
+ in hardware descriptions), \small{GHC} seems to never generate any code
+ making use of this binder. The current prototype does not handle it
+ either, which probably means that code using it would break.
+
+ Note that these case statements are less powerful than the full Haskell
+ case statements. In particular, they do not support complex patterns like
+ in Haskell. Only the constructor of an expression can be matched, complex
+ patterns are implemented using multiple nested case expressions.
+
+ Case statements are also used for unpacking of algebraic datatypes, even
+ when there is only a single constructor. For examples, to add the elements
+ of a tuple, the following Core is generated:
+
+ \startlambda
+ sum = λtuple.case tuple of
+ (,) a b -> a + b
+ \stoplambda
- The type of \lam{fst} has two universally quantified type variables. When
- \lam{fst} is applied in \lam{fstint}, it is first applied to two types.
- (which are substitued for \lam{a} and \lam{b} in the type of \lam{fst}, so
- the type of \lam{fst} actual type of arguments and result can be found:
- \lam{fst @Int @Int :: (Int, Int) -> Int}).
- \stopdesc
+ Here, there is only a single alternative (but no \lam{DEFAULT}
+ alternative, since the single alternative is already exhaustive). When
+ it's body is evaluated, the arguments to the tuple constructor \lam{(,)}
+ (\eg, the elements of the tuple) are bound to \lam{a} and \lam{b}.
+ \stopdesc
+
+ \startdesc{Cast expression}
+ \startlambda
+ body :: targettype
+ \stoplambda
+ A cast expression allows you to change the type of an expression to an
+ equivalent type. Note that this is not meant to do any actual work, like
+ conversion of data from one format to another, or force a complete type
+ change. Instead, it is meant to change between different representations
+ of the same type, \eg switch between types that are provably equal (but
+ look different).
+
+ In our hardware descriptions, we typically see casts to change between a
+ Haskell newtype and its contained type, since those are effectively
+ different representations of the same type.
+
+ More complex are types that are proven to be equal by the typechecker,
+ but look different at first glance. To ensure that, once the typechecker
+ has proven equality, this information sticks around, explicit casts are
+ added. In our notation we only write the target type, but in reality a
+ cast expressions carries around a \emph{coercion}, which can be seen as a
+ proof of equality. TODO: Example
+
+ The value of a cast is the value of its body, unchanged. The type of this
+ value is equal to the target type, not the type of its body.
+
+ Note that this syntax is also used sometimes to indicate that a particular
+ expression has a particular type, even when no cast expression is
+ involved. This is then purely informational, since the only elements that
+ are explicitely typed in the Core language are the binder references and
+ cast expressions, the types of all other elements are determined at
+ runtime.
+ \stopdesc
+
+ \startdesc{Note}
+
+ The Core language in \small{GHC} allows adding \emph{notes}, which serve
+ as hints to the inliner or add custom (string) annotations to a core
+ expression. These shouldn't be generated normally, so these are not
+ handled in any way in the prototype.
+ \stopdesc
+
+ \startdesc{Type}
+ \startlambda
+ @type
+ \stoplambda
+ It is possibly to use a Core type as a Core expression. This is done to
+ allow for type abstractions and applications to be handled as normal
+ lambda abstractions and applications above. This means that a type
+ expression in Core can only ever occur in the argument position of an
+ application, and only if the type of the function that is applied to
+ expects a type as the first argument. This happens for all polymorphic
+ functions, for example, the \lam{fst} function:
+
+ \startlambda
+ fst :: \forall a. \forall b. (a, b) -> a
+ fst = λtup.case tup of (,) a b -> a
+
+ fstint :: (Int, Int) -> Int
+ fstint = λa.λb.fst @Int @Int a b
+ \stoplambda
+
+ The type of \lam{fst} has two universally quantified type variables. When
+ \lam{fst} is applied in \lam{fstint}, it is first applied to two types.
+ (which are substitued for \lam{a} and \lam{b} in the type of \lam{fst}, so
+ the type of \lam{fst} actual type of arguments and result can be found:
+ \lam{fst @Int @Int :: (Int, Int) -> Int}).
+ \stopdesc
+
+ \subsection{Core type system}
+ Whereas the expression syntax of Core is very simple, its type system is
+ a bit more complicated. It turns out it is harder to \quote{desugar}
+ Haskell's complex type system into something more simple. Most of the
+ type system is thus very similar to that of Haskell.
- TODO: Core type system
+ We will slightly limit our view on Core's type system, since the more
+ complicated parts of it are only meant to support Haskell's (or rather,
+ \GHC's) type extensions, such as existential types, type families and
+ other non-standard Haskell stuff which we don't (plan to) support.
+ In Core, every expression is typed. The translation to Core happens
+ after the typechecker, so types in Core are always correct as well
+ (though you could of course construct invalidly typed expressions).
+
+ Any type in core is one of the following:
+
+ \startdesc{A type variable}
+ \startlambda
+ a
+ \stoplambda
+
+ This is a reference to a type defined elsewhere. This can either be a
+ polymorphic type (like \hs{a} in \hs{id :: a -> a}), or a type
+ constructor (like \hs{Bool} in \hs{null :: [a] -> Bool}).
+
+ A special case of a type constructor is the \emph{function type
+ constructor}, \hs{->}. This is a type constructor taking two arguments
+ (using application below). The function type constructor is commonly
+ written inline, so we write \hs{a -> b} when we really mean \hs{-> a
+ b}, the function type constructor applied to a and b.
+
+ Polymorphic type variables can only be defined by a lambda
+ abstraction, see the forall type below.
+ \stopdesc
+
+ \startdesc{A type application}
+ \startlambda
+ Maybe Int
+ \stoplambda
+
+ This applies a some type to another type. This is particularly used to
+ apply type variables (type constructors) to their arguments.
+
+ As mentioned above, some type applications have special notation. In
+ particular, these are applications of the \emph{function type
+ constructor} and \emph{tuple type constructors}:
+ \starthaskell
+ foo :: a -> b
+ foo' :: -> a b
+ bar :: (a, b, c)
+ bar' :: (,,) a b c
+ \stophaskell
+ \stopdesc
+
+ \startdesc{The forall type}
+ \startlambda
+ id :: \forall a . a -> a
+ \stoplambda
+ The forall type introduces polymorphism. It is the only way to
+ introduce new type variables, which are completely unconstrained (Any
+ possible type can be assigned to it). Constraints can be added later
+ using predicate types, see below.
+
+ A forall type is always (and only) introduced by a type lambda
+ expression. For example, the Core translation of the
+ id function is:
+ \startlambda
+ id = λa.λx.x
+ \stoplambda
+
+ here, type type of the binder \lam{x} is \lam{a}, referring to the
+ binder in the topmost lambda.
+
+ When using a value with a forall type, the actual type
+ used must be applied first. For example haskell expression \hs{id
+ True} translates to the following Core:
+
+ \startlambda
+ id @Bool True
+ \stoplambda
+
+ Here, id is first applied to the type to work with. Note that the type
+ then changes from \lam{id :: \forall a . a -> a} to \lam{id @Bool ::
+ Bool -> Bool}. Note that the type variable \lam{a} has been
+ substituted with the actual type.
+ \stopdesc
+
+ \startdesc{Predicate type}
+ \startlambda
+ show :: \forall a. Show s => s -> String
+ \stoplambda
+
+ TODO: Introduce type classes?
+
+ A predicate type introduces a constraint on a type variable introduced
+ by a forall type (or type lambda). In the example above, the type
+ variable \lam{a} can only contain types that are an \emph{instance} of
+ the \emph{type class} \lam{Show}.
+
+ There are other sorts of predicate types, used for the type families
+ extension, which we will not discuss here.
+
+ A predicate type is introduced by a lambda abstraction. Unlike with
+ the forall type, this is a value lambda abstraction, that must be
+ applied to a value. We call this value a \emph{dictionary}.
+
+ Without going into the implementation details, a dictionary can be
+ seen as a lookup table all the methods for a given (single) type class
+ instance. This means that all the dictionaries for the same type class
+ look the same (\eg contain methods with the same names). However,
+ dictionaries for different instances of the same class contain
+ different methods, of course.
+
+ A dictionary is introduced by \small{GHC} whenever it encounters an
+ instance declaration. This dictionary, as well as the binder
+ introduced by a lambda that introduces a dictionary, have the
+ predicate type as their type. These binders are usually named starting
+ with a \lam{\$}. Usually the name of the type concerned is not
+ reflected in the name of the dictionary, but the name of the type
+ class is. The Haskell expression \hs{show True} thus becomes:
+
+ \startlambda
+ show @Bool $dShow True
+ \stoplambda
+ \stopdesc
+
+ Using this set of types, all types in basic Haskell can be represented.
+
\section[sec:prototype:statetype]{State annotations in Haskell}
+ TODO: This section should be reviewed and expanded.
+
Ideal: Type synonyms, since there is no additional code overhead for
packing and unpacking. Downside: there is no explicit conversion in Core
either, so type synonyms tend to get lost in expressions (they can be
(un)packing substates. This will result in many nested State constructors
in a nested state type. \eg:
- \starttyping
- State (State Bit, State (State Word, Bit), Word)
- \stoptyping
+ \starttyping
+ State (State Bit, State (State Word, Bit), Word)
+ \stoptyping
Alternative: Provide different newtypes for input and output state. This
makes the code even more explicit, and typechecking can find even more
errors. However, this requires defining two type synomyms for each
stateful function instead of just one. \eg:
- \starttyping
- type AccumStateIn = StateIn Bit
- type AccumStateOut = StateOut Bit
- \stoptyping
+
+ \starttyping
+ type AccumStateIn = StateIn Bit
+ type AccumStateOut = StateOut Bit
+ \stoptyping
+
This also increases the possibility of having different input and output
states. Checking for identical input and output state types is also
harder, since each element in the state must be unpacked and compared
Alternative: Provide a type for the entire result type of a stateful
function, not just the state part. \eg:
- \starttyping
- newtype Result state result = Result (state, result)
- \stoptyping
+ \starttyping
+ newtype Result state result = Result (state, result)
+ \stoptyping
This makes it easy to say "Any stateful function must return a
\type{Result} type, without having to sort out result from state. However,
look at the whole, we can conclude the following:
\startitemize
- \item A state unpack operation should not generate any \small{VHDL}. The binder
- to which the unpacked state is bound should still be declared, this signal
- will become the register and will hold the current state.
- \item A state pack operation should not generate any \small{VHDL}. The binder th
- which the packed state is bound should not be declared. The binder that is
- packed is the signal that will hold the new state.
- \item Any values of a State type should not be translated to \small{VHDL}. In
- particular, State elements should be removed from tuples (and other
- datatypes) and arguments with a state type should not generate ports.
- \item To make the state actually work, a simple \small{VHDL} proc should be
- generated. This proc updates the state at every clockcycle, by assigning
- the new state to the current state. This will be recognized by synthesis
- tools as a register specification.
+ \item A state unpack operation should not generate any \small{VHDL}. The binder
+ to which the unpacked state is bound should still be declared, this signal
+ will become the register and will hold the current state.
+ \item A state pack operation should not generate any \small{VHDL}. The binder th
+ which the packed state is bound should not be declared. The binder that is
+ packed is the signal that will hold the new state.
+ \item Any values of a State type should not be translated to \small{VHDL}. In
+ particular, State elements should be removed from tuples (and other
+ datatypes) and arguments with a state type should not generate ports.
+ \item To make the state actually work, a simple \small{VHDL} proc should be
+ generated. This proc updates the state at every clockcycle, by assigning
+ the new state to the current state. This will be recognized by synthesis
+ tools as a register specification.
\stopitemize
Implementation issues: state splitting, linking input to output state,
checking usage constraints on state variables.
- Implementation issues
- \subsection[sec:prototype:separate]{Separate compilation}
- - Simplified core?
-
- \section{Haskell language coverage and constraints}
- Recursion
- Builtin types
- Custom types (Sum types, product types)
- Function types / higher order expressions
+ TODO: Implementation issues
+ TODO: \subsection[sec:prototype:separate]{Separate compilation}
+ TODO: Simplified core?
projects / matthijs / master-project / report.git / blobdiff