From 14ba857230ddd3bed3e9fbdde81ad2f693488493 Mon Sep 17 00:00:00 2001 From: Matthijs Kooijman Date: Tue, 8 Dec 2009 18:15:56 +0100 Subject: [PATCH] Say Core instead of core. --- Chapters/Normalization.tex | 20 ++++++++++---------- Chapters/Prototype.tex | 32 ++++++++++++++++---------------- Outline | 1 - 3 files changed, 26 insertions(+), 27 deletions(-) diff --git a/Chapters/Normalization.tex b/Chapters/Normalization.tex index a811bfe..1d65f4a 100644 --- a/Chapters/Normalization.tex +++ b/Chapters/Normalization.tex @@ -21,12 +21,12 @@ \stopcombination } - The first step in the core to \small{VHDL} translation process, is normalization. We - aim to bring the core description into a simpler form, which we can + The first step in the Core to \small{VHDL} translation process, is normalization. We + aim to bring the Core description into a simpler form, which we can subsequently translate into \small{VHDL} easily. This normal form is needed because - the full core language is more expressive than \small{VHDL} in some + the full Core language is more expressive than \small{VHDL} in some areas (higher-order expressions, limited polymorphism using type - classes, etc.) and because core can describe expressions that do not + classes, etc.) and because Core can describe expressions that do not have a direct hardware interpretation. \section{Normal form} @@ -320,7 +320,7 @@ Now we have some intuition for the normal form, we can describe how we want the normal form to look like in a slightly more formal manner. The EBNF-like description in \in{definition}[def:IntendedNormal] captures - most of the intended structure (and generates a subset of \GHC's core + most of the intended structure (and generates a subset of \GHC's Core format). There are two things missing from this definition: cast expressions are @@ -712,7 +712,7 @@ \subsection[sec:normalization:uniq]{Binder uniqueness} A common problem in transformation systems, is binder uniqueness. When not considering this problem, it is easy to create transformations that mix up - bindings and cause name collisions. Take for example, the following core + bindings and cause name collisions. Take for example, the following Core expression: \startlambda @@ -1430,7 +1430,7 @@ function type. Since these can be any expression, there is no transformation needed. Note that this category is exactly all expressions that are not transformed by the transformations for the - previous two categories. This means that \emph{any} core expression + previous two categories. This means that \emph{any} Core expression that is used as an argument to a built-in function will be either transformed into one of the above categories, or end up in this categorie. In any case, the result is in normal form. @@ -2255,7 +2255,7 @@ there are probably expressions involving cast expressions that cannot be brought into intended normal form by this transformation system. - The uses of casts in the core system should be investigated more and + The uses of casts in the Core system should be investigated more and transformations will probably need updating to handle them in all cases. @@ -2503,7 +2503,7 @@ our compilation to \VHDL. The main difference seems to be that in hardware every expression is always evaluated, while in software it is only evaluated if needed, but it should be possible to - assign a meaning to core expressions that assumes neither. + assign a meaning to Core expressions that assumes neither. Since each of the transformations can be applied to any subexpression as well, there is a constraint on our meaning @@ -2543,7 +2543,7 @@ By systematically reviewing the entire Core language definition along with the intended normal form definition (both of which have a similar structure), it should be possible to identify all - possible (sets of) core expressions that are not in intended + possible (sets of) Core expressions that are not in intended normal form and identify a transformation that applies to it. This approach is especially useful for proving completeness of our diff --git a/Chapters/Prototype.tex b/Chapters/Prototype.tex index 390e98b..e2e5db7 100644 --- a/Chapters/Prototype.tex +++ b/Chapters/Prototype.tex @@ -49,7 +49,7 @@ } Considering that we required a prototype which should be working quickly, and that implementing parsers, semantic checkers and especially - typcheckers is not exactly the core of this research (but it is lots and + typcheckers is not 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 @@ -220,7 +220,7 @@ Assuming that we do not want to deal with (or modify) parsing, typechecking and other frontend business and that native code is not really a useful format anymore, we are left with the choice between the full Haskell - \small{AST}, or the smaller (simplified) core representation. + \small{AST}, or the smaller (simplified) Core representation. 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 @@ -228,15 +228,15 @@ the full \small{AST} is a very complicated datastructure. If we are to handle everything it offers, we will quickly get a big compiler. - Using the core representation gives us a much more compact datastructure - (a core expression only uses 9 constructors). Note that this does not mean - that the core representation itself is smaller, on the contrary. - Since the core language has less constructs, most Core expressions + Using the Core representation gives us a much more compact datastructure + (a Core expression only uses 9 constructors). Note that this does not mean + that the Core representation itself is smaller, on the contrary. + Since the Core language has less constructs, most Core expressions are larger than the equivalent versions in Haskell. - However, the fact that the core language is so much smaller, means it is a + 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 + reason, \small{GHC} runs its simplifications and optimizations on the Core representation as well \cite[jones96]. We will use the normal Core representation, not the simplified Core. Even @@ -286,15 +286,15 @@ translates Haskell sources to a typed Core representation. \stopdesc \startdesc{Normalization} - This is a step that transforms the core representation into a normal - form. This normal form is still expressed in the core language, but has + This is a step that transforms the Core representation into a normal + form. This normal form is still expressed in the Core language, but has to adhere to an additional set of constraints. This normal form is less - expressive than the full core language (e.g., it can have limited + expressive than the full Core language (e.g., it can have limited higher-order expressions, has a specific structure, etc.), but is also very close to directly describing hardware. \stopdesc \startdesc{\small{VHDL} generation} - The last step takes the normal formed core representation and generates + The last step takes the normal formed Core representation and generates \small{VHDL} for it. Since the normal form has a specific, hardware-like structure, this final step is very straightforward. \stopdesc @@ -312,7 +312,7 @@ any functions used by the entry functions (recursively). \section[sec:prototype:core]{The Core language} - \defreftxt{core}{the Core language} + \defreftxt{Core}{the Core language} Most of the prototype deals with handling the program in the Core language. In this section we will show what this language looks like and how it works. @@ -383,7 +383,7 @@ for normal function \quote{calls}, but also for applying type abstractions and data constructors. - In core, there is no distinction between an operator and a + In Core, there is no distinction between an operator and a function. This means that, for example the addition of two numbers looks like the following in Core: @@ -626,7 +626,7 @@ \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 + as hints to the inliner or add custom (string) annotations to a Core expression. These should not be generated normally, so these are not handled in any way in the prototype. \stopdesc @@ -698,7 +698,7 @@ (though you could of course construct invalidly typed expressions through the \GHC\ API). - Any type in core is one of the following: + Any type in Core is one of the following: \startdesc{A type variable} \startlambda diff --git a/Outline b/Outline index bbcf46a..e24089c 100644 --- a/Outline +++ b/Outline @@ -53,7 +53,6 @@ TODO: Register TODO: Variable vs binder TODO: simplification -> Normalisation? TODO: Use saturated (application) instead of complete (application)? -TODO: core => Core TODO: Say something about implementation differences with transformation specs TODO: Say something about the builtin functions somewhere (ref: christiaan) TODO: Future work: Use Cλash -- 2.30.2