+ The lexical and syntactic analyser for Haskell programs are located in
+ fptools/ghc/compiler/parser/.
+
+ The lexer is a rather tedious piece of Haskell code contained in the
+ module Lex.
+ Its complexity partially stems from covering, in addition to Haskell 98,
+ also the whole range of GHC language extensions plus its ability to
+ analyse interface files in addition to normal Haskell source. The lexer
+ defines a parser monad P a, where a is the
+ type of the result expected from a successful parse. More precisely, a
+ result of type
+
++data ParseResult a = POk PState a + | PFailed Message+
+ is produced with Message being from ErrUtils
+ (and currently is simply a synonym for SDoc).
+
+ The record type PState contains information such as the
+ current source location, buffer state, contexts for layout processing,
+ and whether Glasgow extensions are accepted (either due to
+ -fglasgow-exts or due to reading an interface file). Most
+ of the fields of PState store unboxed values; in fact, even
+ the flag indicating whether Glasgow extensions are enabled is
+ represented by an unboxed integer instead of by a Bool. My
+ (= chak's) guess is that this is to avoid having to perform a
+ case on a boxed value in the inner loop of the lexer.
+
+ The same lexer is used by the Haskell source parser, the Haskell + interface parser, and the package configuration parser. + +
+ The parser for Haskell source files is defined in the form of a parser
+ specification for the parser generator Happy in the file Parser.y.
+ The parser exports three entry points for parsing entire modules
+ (parseModule, individual statements
+ (parseStmt), and individual identifiers
+ (parseIdentifier), respectively. The last two are needed
+ for GHCi. All three require a parser state (of type
+ PState) and are invoked from HscMain.
+
+ Parsing of Haskell is a rather involved process. The most challenging
+ features are probably the treatment of layout and expressions that
+ contain infix operators. The latter may be user-defined and so are not
+ easily captured in a static syntax specification. Infix operators may
+ also appear in the right hand sides of value definitions, and so, GHC's
+ parser treats those in the same way as expressions. In other words, as
+ general expressions are a syntactic superset of expressions - ok, they
+ nearly are - the parser simply attempts to parse a general
+ expression in such positions. Afterwards, the generated parse tree is
+ inspected to ensure that the accepted phrase indeed forms a legal
+ pattern. This and similar checks are performed by the routines from ParseUtil. In
+ some cases, these routines do, in addition to checking for
+ wellformedness, also transform the parse tree, such that it fits into
+ the syntactic context in which it has been parsed; in fact, this happens
+ for patterns, which are transformed from a representation of type
+ RdrNameHsExpr into a representation of type
+ RdrNamePat.
+
+
+ The parser for interface files is also generated by Happy from ParseIface.y.
+ It's main routine parseIface is invoked from RnHiFiles.readIface.
+
+
+ The parser for configuration files is by far the smallest of the three
+ and defined in ParsePkgConf.y.
+ It exports loadPackageConfig, which is used by DriverState.readPackageConf.
+
+
+ +Last modified: Wed Jan 16 00:30:14 EST 2002 + + + +