discuss it any further, since it is not required for our prototype.
\stopdesc
- In this process, there a number of places where we can start our work.
+ In this process, there are a number of places where we can start our work.
Assuming that we don't want to deal with (or modify) parsing, typechecking
and other frontend business and that native code isn't really a useful
format anymore, we are left with the choice between the full Haskell
The advantage of taking the full \small{AST} is that the exact structure
of the source program is preserved. We can see exactly what the hardware
- descriiption looks like and which syntax constructs were used. However,
+ description looks like and which syntax constructs were used. However,
the full \small{AST} is a very complicated datastructure. If we are to
handle everything it offers, we will quickly get a big compiler.
However, the fact that the core language is so much smaller, means it is a
lot easier to analyze and translate it into something else. For the same
reason, \small{GHC} runs its simplifications and optimizations on the core
- representation as well.
+ representation as well \cite[jones96].
However, we will use the normal core representation, not the simplified
core. Reasons for this are detailed below. \todo{Ref}
binder (the function name) to an expression (the function value, which has
a function type).
- The Core language itself does not prescribe any program structure, only
- expression structure. In the \small{GHC} compiler, the Haskell module
- structure is used for the resulting Core code as well. Since this is not
- so relevant for understanding the Core language or the Normalization
+ The Core language itself does not prescribe any program structure
+ (like modules, declarations, imports, etc.), only expression
+ structure. In the \small{GHC} compiler, the Haskell module structure
+ is used for the resulting Core code as well. Since this is not so
+ relevant for understanding the Core language or the Normalization
process, we'll only look at the Core expression language here.
Each Core expression consists of one of these possible expressions.
\startdesc{Variable reference}
\defref{variable reference}
\startlambda
- x :: T
+ bndr :: T
\stoplambda
This is a reference to a binder. It's written down as the
name of the binder that is being referred to along with its type. The
- binder name should of course be bound in a containing scope (including
- top level scope, so a reference to a top level function is also a
- variable reference). Additionally, constructors from algebraic datatypes
- also become variable references.
+ binder name should of course be bound in a containing scope
+ (including top level scope, so a reference to a top level function
+ is also a variable reference). Additionally, constructors from
+ algebraic datatypes also become variable references.
- The value of this expression is the value bound to the given binder.
+ In our examples, binders will commonly consist of a single
+ characters, but they can have any length.
+
+ The value of this expression is the value bound to the given
+ binder.
Each binder also carries around its type (explicitly shown above), but
this is usually not shown in the Core expressions. Only when the type is
\stoplambda
This is a 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).
+ \quote{primitive}, unboxed versions, like \lam{Char\#} and \lam{Word\#}, not the
+ normal Haskell versions (but there are builtin conversion
+ functions). Without going into detail about these types, note that
+ a few conversion functions exist to convert these to the normal
+ (boxed) Haskell equivalents.
\stopdesc
\startdesc{Application}
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
- other words, the lambda abstraction \quote{operator} has the lowest
- priority of all.
+ The body of a lambda abstraction extends all the way to the end of
+ the expression, or the closing bracket surrounding the lambda. In
+ other words, the lambda abstraction \quote{operator} has the
+ lowest priority of all.
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.
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
+ evaluating to some other value (for which that binder is in scope). This
allows for sharing of subexpressions (you can use a binder twice) and
- explicit \quote{naming} of arbitrary expressions. Note that the binder
- is not in scope in the value bound to it, so it's not possible to make
- recursive definitions with the normal form of the let expression (see
- the recursive form below).
+ explicit \quote{naming} of arbitrary expressions. A binder is not
+ in scope in the value bound it is bound to, so it's not possible
+ to make recursive definitions with a non-recursive let expression
+ (see the recursive form below).
Even though this let expression is an extension on the basic lambda
calculus, it is easily translated to a lambda abstraction. The let
binders is in scope in each of the values, in addition to the body. This
allows for self-recursive or mutually recursive definitions.
- It should also be possible to express a recursive let using normal
- lambda calculus, if we use the \emph{least fixed-point operator},
- \lam{Y}. This falls beyond the scope of this report, since it is not
- needed for this research.
+ It is also possible to express a recursive let expression using
+ normal lambda calculus, if we use the \emph{least fixed-point
+ operator}, \lam{Y} (but the details are too complicated to help
+ clarify the let expression, so this will not be explored further).
\stopdesc
+ \placeintermezzo{}{
+ \startframedtext[width=8cm,background=box,frame=no]
+ \startalignment[center]
+ {\tfa Weak head normal form (\small{WHNF})}
+ \stopalignment
+ \blank[medium]
+ An expression is in weak head normal form if it is either an
+ constructor application or lambda abstraction. \todo{How about
+ atoms?}
+
+ Without going into detail about the differences with head
+ normal form and normal form, note that evaluating the scrutinee
+ of a case expression to normal form (evaluating any function
+ applications, variable references and case expressions) is
+ sufficient to decide which case alternatives should be chosen.
+ \todo{ref?}
+ \stopframedtext
+
+ }
+
\startdesc{Case expression}
\defref{case expression}
\startlambda
Cn bndrn,0 ... bndrn,m -> bodyn
\stoplambda
- \todo{Define WHNF}
-
A case expression is the only way in Core to choose between values. All
\hs{if} expressions and pattern matchings from the original Haskell
PRogram have been translated to case expressions by the desugarer.
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. A case expression must always be
- exhaustive, \ie it must cover all possible constructors that the
- scrutinee can have (if all of them are covered explicitly, the
- \lam{DEFAULT} alternative can be left out).
+ (optionally) binds it to \lam{bndr}. Every alternative lists a
+ single constructor (\lam{C0 ... Cn}). Based on the actual
+ constructor of the scrutinee, the corresponding alternative is
+ chosen. The binders in the chosen alternative (\lam{bndr0,0 ....
+ bndr0,m} are bound to the actual arguments to the constructor in
+ the scrutinee.
+
+ This is best illustrated with an example. Assume
+ there is an algebraic datatype declared as follows\footnote{This
+ datatype is not suported by the current Cλash implementation, but
+ serves well to illustrate the case expression}:
+
+ \starthaskell
+ data D = A Word | B Bit
+ \stophaskell
+
+ This is an algebraic datatype with two constructors, each getting
+ a single argument. A case expression scrutinizing this datatype
+ could look like the following:
+
+ \startlambda
+ case s of
+ A word -> High
+ B bit -> bit
+ \stoplambda
+
+ What this expression does is check the constructor of the
+ scrutinee \lam{s}. If it is \lam{A}, it always evaluates to
+ \lam{High}. If the constructor is \lam{B}, the binder \lam{bit} is
+ bound to the argument passed to \lam{B} and the case expression
+ evaluates to this bit.
+
+ If none of the alternatives match, the \lam{DEFAULT} alternative
+ is chosen. A case expression must always be exhaustive, \ie it
+ must cover all possible constructors that the scrutinee can have
+ (if all of them are covered explicitly, the \lam{DEFAULT}
+ alternative can be left out).
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
\small{WHNF}, even when there is only a \lam{DEFAULT} alternative. This
allows aplication of the strict function \lam{f} to the argument \lam{a}
\startdesc{Type}
\defref{type expression}
\startlambda
- @type
+ @T
\stoplambda
- It is possibly to use a Core type as a Core expression. For the actual
- types supported by Core, see \in{section}[sec:prototype:coretypes]. This
- \quote{lifting} of a type into the value domain 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:
+ It is possibly to use a Core type as a Core expression. To prevent
+ confusion between types and values, the \lam{@} sign is used to
+ explicitly mark a type that is used in a Core expression.
+
+ For the actual types supported by Core, see
+ \in{section}[sec:prototype:coretypes]. This \quote{lifting} of a
+ type into the value domain 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
+ fst :: \forall t1. \forall t2. (t1, t2) ->t1
+ fst = λt1.λt2.λ(tup :: (t1, t2)). case tup of (,) a b -> a
fstint :: (Int, Int) -> Int
fstint = λa.λb.fst @Int @Int a b
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:
+ (which are substitued for \lam{t1} and \lam{t2} in the type of \lam{fst}, so
+ the actual type of arguments and result of \lam{fst} can be found:
\lam{fst @Int @Int :: (Int, Int) -> Int}).
\stopdesc
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).
+ (though you could of course construct invalidly typed expressions
+ through the \GHC API).
Any type in core is one of the following:
Maybe Int
\stoplambda
- This applies a some type to another type. This is particularly used to
+ This applies some type to another type. This is particularly used to
apply type variables (type constructors) to their arguments.
As mentioned above, applications of some type constructors have
special notation. In particular, these are applications of the
\emph{function type constructor} and \emph{tuple type constructors}:
\startlambda
- foo :: a -> b
- foo' :: -> a b
- bar :: (a, b, c)
- bar' :: (,,) a b c
+ foo :: t1 -> t2
+ foo' :: -> t1 t2
+ bar :: (t1, t2, t3)
+ bar' :: (,,) t1 t2 t3
\stoplambda
\stopdesc
\startdesc{The forall type}
\startlambda
- id :: \forall a. a -> a
+ id :: \forall t. t -> t
\stoplambda
The forall type introduces polymorphism. It is the only way to
introduce new type variables, which are completely unconstrained (Any
expression. For example, the Core translation of the
id function is:
\startlambda
- id = λa.λx.x
+ id = λt.λ(x :: t).x
\stoplambda
- Here, the type of the binder \lam{x} is \lam{a}, referring to the
+ Here, the type of the binder \lam{x} is \lam{t}, referring to the
binder in the topmost lambda.
When using a value with a forall type, the actual type
\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 ::
+ then changes from \lam{id :: \forall t. t -> t} to \lam{id @Bool ::
Bool -> Bool}. Note that the type variable \lam{a} has been
substituted with the actual type.
\startdesc{Predicate type}
\startlambda
- show :: \forall a. Show s ⇒ s → String
+ show :: \forall t. Show t ⇒ t → String
\stoplambda
\todo{Sidenote: 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
+ variable \lam{t} can only contain types that are an \emph{instance} of
the \emph{type class} \lam{Show}. \refdef{type class}
There are other sorts of predicate types, used for the type families
\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 To make the state actually work, a simple \small{VHDL}
+ (sequential) process should be generated. This process 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
When applying these rules to the description in
actual flow of values in the final hardware.
\startlambda
- avg = iλ.--λspacked.--
+ avg = iλ.λ--spacked.--
let
s = --spacked ▶ (AccState, Word)--
--accs = case s of (accs, _) -> accs--
When we would really leave out the crossed out parts, we get a slightly
weird program: There is a variable \lam{s} which has no value, and there
is a variable \lam{s'} that is never used. Together, these two will form
- the state proc of the function. \lam{s} contains the "current" state,
+ the state process of the function. \lam{s} contains the "current" state,
\lam{s'} is assigned the "next" state. So, at the end of each clock
cycle, \lam{s'} should be assigned to \lam{s}.
projects / matthijs / master-project / report.git / blobdiff