Changes between Version 36 and Version 37 of Commentary/CodingStyle


Ignore:
Timestamp:
Jul 9, 2011 1:45:08 AM (3 years ago)
Author:
dterei
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Commentary/CodingStyle

    v36 v37  
    1  
    21[[PageOutline]] 
    32 
    4  = The GHC Commentary - Coding Style Guidelines for the compiler =  
     3= The GHC Commentary - Coding Style Guidelines for the compiler =  
    54 
    65This is a rough description of some of the coding practices and style that we use for Haskell code inside {{{compiler}}}.  For run-time system code see the [wiki:Commentary/Rts/Conventions Coding Style Guidelines for RTS C code].  Also see the wiki page on [wiki:WorkingConventions Working Conventions] for issues related to version control, workflow, testing, bug tracking and other miscellany. 
     
    1514 
    1615== Comments == 
     16 
    1717=== Comments and commit messages === 
    1818 
     
    178178 
    179179=== {{{HsVersions.h}}} === 
     180 
    180181{{{HsVersions.h}}} is a CPP header file containing a number of macros that help smooth out the differences between compiler versions. It defines, for example, macros for library module names which have moved between versions. Take a look [[GhcFile(compiler/HsVersions.h)]]. 
    181182{{{ 
     
    183184}}} 
    184185 
    185  
    186  
    187186=== Literate Haskell === 
    188187 
    189188In GHC we use a mixture of literate ({{{.lhs}}}) and non-literate ({{{.hs}}}) source. I (Simon M.) prefer to use non-literate style, because I think the {{{\begin{code}..\end{code}}}} clutter up the source too much, and I like to use Haddock-style comments (we haven't tried processing the whole of GHC with Haddock yet, though).  
    190  
    191189=== The C Preprocessor (CPP) === 
    192190 
     
    213211Now you can Google for this error message :-) 
    214212 
    215  
    216213 '''GHCI'''::  
    217214  Enables GHCi support, including the byte code generator and interactive user interface. This isn't the default, because the compiler needs to be bootstrapped with itself in order for GHCi to work properly. The reason is that the byte-code compiler and linker are quite closely tied to the runtime system, so it is essential that GHCi is linked with the most up-to-date RTS. Another reason is that the representation of certain datatypes must be consistent between GHCi and its libraries, and if these were inconsistent then disaster could follow.  
    218215 
     216=== Platform tests === 
     217 
     218There are three platforms of interest to GHC: 
     219  
     220 * The '''Build''' platform. This is the platform on which we are building GHC. 
     221 * The '''Host''' platform. This is the platform on which we are going to run this GHC binary, and associated tools. 
     222 * The '''Target''' platform. This is the platform for which this GHC binary will generate code. 
     223 
     224At the moment, there is very limited support for having different values for buil, host, and target.  In particular: 
     225 
     226 * The build platform is currently always the same as the host platform.  The build process needs to use some of the tools in 
     227the source tree, for example `ghc-pkg` and `hsc2hs` 
     228 
     229 * If the target platform differs from the host platform, then this is generally for the purpose of building `.hc` files from Haskell source for porting GHC to the target platform. Full cross-compilation isn't supported (yet). 
     230 
     231In the compiler's source code, you may make use of the following CPP symbols: 
     232 
     233 * ''xxx''`_TARGET_ARCH` 
     234 * ''xxx''`_TARGET_VENDOR` 
     235 * ''xxx''`_TARGET_OS` 
     236 * ''xxx''`_HOST_ARCH` 
     237 * ''xxx''`_HOST_VENDOR` 
     238 * ''xxx''`_HOST_OS` 
     239 
     240where ''xxx'' is the appropriate value: eg. `i386_TARGET_ARCH`.