docs/comm/the-beast/syntax.html

   1 <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
   2 <html>
   3   <head>
   4     <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=ISO-8859-1">
   5     <title>The GHC Commentary - Just Syntax</title>
   6   </head>
   7
   8   <body BGCOLOR="FFFFFF">
   9     <h1>The GHC Commentary - Just Syntax</h1>
  10     <p>
  11       The lexical and syntactic analyser for Haskell programs are located in
  12       <a
  13       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/"><code>fptools/ghc/compiler/parser/</code></a>.
  14     </p>
  15
  16     <h2>The Lexer</h2>
  17     <p>
  18       The lexer is a rather tedious piece of Haskell code contained in the
  19       module <a
  20       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/Lex.lhs"><code>Lex</code></a>.
  21       Its complexity partially stems from covering, in addition to Haskell 98,
  22       also the whole range of GHC language extensions plus its ability to
  23       analyse interface files in addition to normal Haskell source.  The lexer
  24       defines a parser monad <code>P a</code>, where <code>a</code> is the
  25       type of the result expected from a successful parse.  More precisely, a
  26       result of type
  27 <blockquote><pre>
  28 data ParseResult a = POk PState a
  29                    | PFailed Message</pre>
  30 </blockquote>
  31     <p>
  32       is produced with <code>Message</code> being from <a
  33       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/ErrUtils.lhs"><code>ErrUtils</code></a>
  34       (and currently is simply a synonym for <code>SDoc</code>).
  35     <p>
  36       The record type <code>PState</code> contains information such as the
  37       current source location, buffer state, contexts for layout processing,
  38       and whether Glasgow extensions are accepted (either due to
  39       <code>-fglasgow-exts</code> or due to reading an interface file).  Most
  40       of the fields of <code>PState</code> store unboxed values; in fact, even
  41       the flag indicating whether Glasgow extensions are enabled is
  42       represented by an unboxed integer instead of by a <code>Bool</code>.  My
  43       (= chak's) guess is that this is to avoid having to perform a
  44       <code>case</code> on a boxed value in the inner loop of the lexer.
  45     <p>
  46       The same lexer is used by the Haskell source parser, the Haskell
  47       interface parser, and the package configuration parser.
  48
  49     <h2>The Haskell Source Parser</h2>
  50     <p>
  51       The parser for Haskell source files is defined in the form of a parser
  52       specification for the parser generator <a
  53       href="http://haskell.org/happy/">Happy</a> in the file <a
  54       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/Parser.y"><code>Parser.y</code></a>.
  55       The parser exports three entry points for parsing entire modules
  56       (<code>parseModule</code>, individual statements
  57       (<code>parseStmt</code>), and individual identifiers
  58       (<code>parseIdentifier</code>), respectively.  The last two are needed
  59       for GHCi.  All three require a parser state (of type
  60       <code>PState</code>) and are invoked from <a
  61       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/HscMain.lhs"><code>HscMain</code></a>.
  62     <p>
  63       Parsing of Haskell is a rather involved process.  The most challenging
  64       features are probably the treatment of layout and expressions that
  65       contain infix operators.  The latter may be user-defined and so are not
  66       easily captured in a static syntax specification.  Infix operators may
  67       also appear in the right hand sides of value definitions, and so, GHC's
  68       parser treats those in the same way as expressions.  In other words, as
  69       general expressions are a syntactic superset of expressions - ok, they
  70       <em>nearly</em> are - the parser simply attempts to parse a general
  71       expression in such positions.  Afterwards, the generated parse tree is
  72       inspected to ensure that the accepted phrase indeed forms a legal
  73       pattern.  This and similar checks are performed by the routines from <a
  74       href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/parser/ParseUtil.lhs"><code>ParseUtil</code></a>. In
  75       some cases, these routines do, in addition to checking for
  76       wellformedness, also transform the parse tree, such that it fits into
  77       the syntactic context in which it has been parsed; in fact, this happens
  78       for patterns, which are transformed from a representation of type
  79       <code>RdrNameHsExpr</code> into a representation of type
  80       <code>RdrNamePat</code>.
  81
  82     <h2>The Haskell Interface Parser</h2>
  83     <p>
  84       The parser for interface files is also generated by Happy from <a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/rename/ParseIface.y"><code>ParseIface.y</code></a>.
  85       It's main routine <code>parseIface</code> is invoked from <a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/rename/RnHiFiles.lhs"><code>RnHiFiles</code></a><code>.readIface</code>.
  86
  87     <h2>The Package Configuration Parser</h2>
  88     <p>
  89       The parser for configuration files is by far the smallest of the three
  90       and defined in <a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/ParsePkgConf.y"><code>ParsePkgConf.y</code></a>.
  91       It exports <code>loadPackageConfig</code>, which is used by <a href="http://cvs.haskell.org/cgi-bin/cvsweb.cgi/fptools/ghc/compiler/main/DriverState.hs"><code>DriverState</code></a><code>.readPackageConf</code>.
  92
  93     <p><small>
  94 <!-- hhmts start -->
  95 Last modified: Wed Jan 16 00:30:14 EST 2002
  96 <!-- hhmts end -->
  97     </small>
  98   </body>
  99 </html>