projects
/
matthijs
/
master-project
/
report.git
/ commitdiff
commit
grep
author
committer
pickaxe
?
search:
re
summary
|
shortlog
|
log
|
commit
| commitdiff |
tree
raw
|
patch
|
inline
| side by side (from parent 1:
0ab64c5
)
Replace statement with expression everywhere.
author
Matthijs Kooijman
<matthijs@stdin.nl>
Sat, 5 Dec 2009 20:49:56 +0000
(21:49 +0100)
committer
Matthijs Kooijman
<matthijs@stdin.nl>
Sat, 5 Dec 2009 20:49:56 +0000
(21:49 +0100)
Chapters/Context.tex
patch
|
blob
|
history
Chapters/Future.tex
patch
|
blob
|
history
Chapters/Normalization.tex
patch
|
blob
|
history
Chapters/Prototype.tex
patch
|
blob
|
history
Outline
patch
|
blob
|
history
diff --git
a/Chapters/Context.tex
b/Chapters/Context.tex
index 1b0268922932952500644424fb3916268881fef6..9444a6e8e78b58ea9a25ec1214398456ccedab7f 100644
(file)
--- a/
Chapters/Context.tex
+++ b/
Chapters/Context.tex
@@
-17,7
+17,7
@@
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
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
statement
s in Lava, since they would be
+ language (you can't use case
expression
s 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,
executed only once during circuit generation) and extra notational overhead.
We will now have a look at the existing hardware description languages,
@@
-89,7
+89,7
@@
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
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
statement
s are not supported, a lot of Haskell's
+ used. Since conditional
expression
s 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
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
diff --git
a/Chapters/Future.tex
b/Chapters/Future.tex
index 9c60dfe8e3b8f656ef0bd8a74e67fa6a98b4e80b..4eb297d7e9c3d2b357942bfec82359017a263699 100644
(file)
--- a/
Chapters/Future.tex
+++ b/
Chapters/Future.tex
@@
-126,7
+126,7
@@
Note that the \hs{FooState} type has changed (so indirectly the type of
stateful functions at a time, the final state consists of nested two-tuples.
The final \hs{()} in the state originates from the fact that the \hs{return}
function has no real state, but is part of the composition. We could have left
stateful functions at a time, the final state consists of nested two-tuples.
The final \hs{()} in the state originates from the fact that the \hs{return}
function has no real state, but is part of the composition. We could have left
-out the return
statement
(and the \hs{outb <-} part) to make \hs{foo}'s return
+out the return
expression
(and the \hs{outb <-} part) to make \hs{foo}'s return
value equal to \hs{funcb}'s, but this approach makes it clearer what is
happening.
value equal to \hs{funcb}'s, but this approach makes it clearer what is
happening.
@@
-356,7
+356,7
@@
Note that in the above example the \hs{suba} and \hs{subb} functions are
is calculated as well, but only saved when the right clock has an up
transition.
is calculated as well, but only saved when the right clock has an up
transition.
-As you can see, there is some code duplication in the case
statement
that
+As you can see, there is some code duplication in the case
expression
that
selects the right clock. One of the advantages of an explicit approach like
this, is that some of this duplication can be extracted away into helper
functions. For example, we could imagine a \hs{select_clock} function, which
selects the right clock. One of the advantages of an explicit approach like
this, is that some of this duplication can be extracted away into helper
functions. For example, we could imagine a \hs{select_clock} function, which
@@
-573,7
+573,7
@@
lightly.
This is of course a very intrusive solution. Every type must become member
of this typeclass, and there is now some member in every type that is a
special don't care value. Guaranteeing the obvious don't care semantics
This is of course a very intrusive solution. Every type must become member
of this typeclass, and there is now some member in every type that is a
special don't care value. Guaranteeing the obvious don't care semantics
- also becomes harder, since every pattern match or case
statement
must now
+ also becomes harder, since every pattern match or case
expressions
must now
also take care of the don't care value (this might actually be an
advantage, since it forces designers to specify how to handle don't care
for different operations).
also take care of the don't care value (this might actually be an
advantage, since it forces designers to specify how to handle don't care
for different operations).
diff --git
a/Chapters/Normalization.tex
b/Chapters/Normalization.tex
index 907411e877ef6bb9d2d1a30c67fd5d94774527a5..2979b69034b38de0d3ac87dfce3ef01a39b1345b 100644
(file)
--- a/
Chapters/Normalization.tex
+++ b/
Chapters/Normalization.tex
@@
-551,7
+551,7
@@
\stoplambda
Again, the transformation does not apply to this lambda abstraction, so we
\stoplambda
Again, the transformation does not apply to this lambda abstraction, so we
- look at its body. For brevity, we'll put the case
statement
on one line from
+ look at its body. For brevity, we'll put the case
expression
on one line from
now on.
\startlambda
now on.
\startlambda
@@
-1428,7
+1428,7
@@
\stoptrans
\todo{Check the subscripts of this transformation}
\stoptrans
\todo{Check the subscripts of this transformation}
- Note that this transformation applies to case
statement
s with any
+ Note that this transformation applies to case
expression
s with any
scrutinee. If the scrutinee is a complex expression, this might result
in duplicate hardware. An extra condition to only apply this
transformation when the scrutinee is already simple (effectively
scrutinee. If the scrutinee is a complex expression, this might result
in duplicate hardware. An extra condition to only apply this
transformation when the scrutinee is already simple (effectively
@@
-1481,10
+1481,10
@@
\in{section}[sec:transformation:caseremoval].
\subsubsection[sec:transformation:caseremoval]{Case removal}
\in{section}[sec:transformation:caseremoval].
\subsubsection[sec:transformation:caseremoval]{Case removal}
- This transform removes any case
statements
with a single alternative and
+ This transform removes any case
expression
with a single alternative and
only wild binders.
only wild binders.
- These "useless" case
statement
s are usually leftovers from case simplification
+ These "useless" case
expression
s are usually leftovers from case simplification
on extractor case (see the previous example).
\starttrans
on extractor case (see the previous example).
\starttrans
diff --git
a/Chapters/Prototype.tex
b/Chapters/Prototype.tex
index 037d1ce7570e1ea5bdc3edcd4d68744e227ab796..40663f37cf2edb95d728da97f2e41d7e4e1cbc4b 100644
(file)
--- a/
Chapters/Prototype.tex
+++ b/
Chapters/Prototype.tex
@@
-451,12
+451,12
@@
binder, even when strictness was involved. Nonetheless, the prototype
handles this binder as expected.
binder, even when strictness was involved. Nonetheless, the prototype
handles this binder as expected.
- Note that these case
statement
s are less powerful than the full Haskell
- case
statement
s. In particular, they do not support complex patterns like
+ Note that these case
expression
s are less powerful than the full Haskell
+ case
expression
s. 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.
in Haskell. Only the constructor of an expression can be matched,
complex patterns are implemented using multiple nested case expressions.
- Case
statement
s are also used for unpacking of algebraic datatypes, even
+ Case
expression
s 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:
when there is only a single constructor. For examples, to add the elements
of a tuple, the following Core is generated:
@@
-995,7
+995,7
@@
\emph{one} application, no more and no less.
The function result should contain exactly one state variable, which
\emph{one} application, no more and no less.
The function result should contain exactly one state variable, which
- can be extracted using (multiple) case
statement
s. The extracted
+ can be extracted using (multiple) case
expression
s. The extracted
state variable is referred to the \emph{output substate}
The type of this output substate must be identical to the type of
state variable is referred to the \emph{output substate}
The type of this output substate must be identical to the type of
diff --git
a/Outline
b/Outline
index 3ea03b2cf3ce4c63cad9b486aa6d2fd7506251ac..55d8b86c722579355ed94361f24b253452948d19 100644
(file)
--- a/
Outline
+++ b/
Outline
@@
-49,7
+49,6
@@
TODO: Hardware description / model vs program
TODO: State & pattern matches
TODO: Separate compilation / Prelude
TODO: Add case binder removal transformation
TODO: State & pattern matches
TODO: Separate compilation / Prelude
TODO: Add case binder removal transformation
-TODO: Remove all "statement"s
TODO: User-defined type classes (future work?)
TODO: Entity / Architecture / Component vs Function?
TODO: Expand on "representable"
TODO: User-defined type classes (future work?)
TODO: Entity / Architecture / Component vs Function?
TODO: Expand on "representable"