Editing Glasgow Haskell Compiler (section)

==Architecture==
GHC is [[Bootstrapping (compilers)|written in Haskell]],<ref>
{{Cite web
 | url = https://gitlab.haskell.org/ghc/ghc/wikis/commentary/compiler
 | title = GHC Commentary: The Compiler
 | website = Haskell.org
 | date = 23 March 2016
 | access-date = 26 May 2016
 | url-status = dead 
 | archive-url = https://web.archive.org/web/20160323040632/https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler 
 | archive-date = 23 March 2016
}}
</ref> but the [[Run-time system|runtime system]] for Haskell, essential to run programs, is written in [[C (programming language)|C]] and [[C--]].

GHC's [[Compilers#Front end|front end]], incorporating the [[Lexical analysis|lexer]], parser and [[Type system|typechecker]], is designed to preserve as much information about the source language as possible until after [[type inference]] is complete, toward the goal of providing clear error messages to users.<ref name="history"/> After type checking, the Haskell code is [[Syntactic sugar|desugared]] into a typed [[intermediate language]] known as "Core" (based on [[System F]], extended with <code>let</code> and <code>case</code> expressions). Core has been extended to support [[generalized algebraic datatypes]] in its [[type system]], and is now based on an extension to System F known as System F<sub>C</sub>.<ref name="Sulzmann2007">
{{cite conference
 | last1 = Sulzmann
 | first1 = M.
 | last2 = Chakravarty
 | first2 = M. M. T.
 | last3 = Peyton Jones
 | first3 = S. |author3-link=Simon Peyton Jones
 | last4 = Donnelly
 | first4 = K.
 | date = January 2007
 | title = System F with Type Equality Coercions
 | book-title = Procedures of the ACM Workshop on Types in Language Design and Implementation (TLDI)
 | url = https://www.microsoft.com/en-us/research/publication/system-f-with-type-equality-coercions/
}}
</ref>

In the tradition of type-directed compiling, GHC's simplifier, or "middle end", where most of the [[Compiler optimization|optimizations]] implemented in GHC are performed, is structured as a series of [[Source code|source-to-source]] [[Program transformation|transformations]] on Core code. The analyses and transformations performed in this compiler stage include demand analysis (a generalization of [[strictness analysis]]), application of user-defined [[rewrite rules]] (including a set of rules included in GHC's standard libraries that performs foldr/build [[Deforestation (computer science)|fusion]]), unfolding (called "[[inlining]]" in more traditional compilers), [[let-floating]], an analysis that determines which function arguments can be unboxed, [[constructed product result analysis]], [[Partial evaluation|specialization]] of [[Type class|overloaded]] functions, and a set of simpler local transformations such as [[constant folding]] and [[beta reduction]].<ref name="comp-by-trans">
{{cite conference
 | last = Peyton Jones
 | first = S. |author-link=Simon Peyton Jones
 | date = April 1996
 | title = Compiling Haskell by program transformation: a report from the trenches
 | book-title = Procedures of the European Symposium on Programming (ESOP)
 | url = https://www.microsoft.com/en-us/research/publication/compiling-haskell-by-program-transformation-a-report-from-the-trenches/
}}</ref>

The back end of the compiler transforms Core code into an internal representation of [[C--]], via an intermediate language STG (short for "Spineless Tagless G-machine").<ref name="stg">
{{cite journal
 | last = Peyton Jones
 | first = S. |author-link=Simon Peyton Jones
 | date = April 1992
 | title = Implementing lazy functional languages on stock hardware: the Spineless Tagless G-machine, Version 2.5
 | journal = Journal of Functional Programming
 | volume = 2
 | issue = 2
 | pages = 127–202
 | url = https://www.microsoft.com/en-us/research/publication/implementing-lazy-functional-languages-on-stock-hardware-the-spineless-tagless-g-machine/
 | doi = 10.1017/S0956796800000319
}}</ref> The C-- code can then take one of three routes: it is either printed as C code for compilation with [[GNU Compiler Collection|GCC]], converted directly into native machine code (the traditional "[[Code generation (compiler)|code generation]]" phase), or converted to [[LLVM IR]] for compilation with LLVM. In all three cases, the resultant native code is finally linked against the GHC runtime system to produce an executable.