on master help sign in
Add comments to explain the thought process and structure of the AST
commit1191c8a6659e84659dbf4935fc9ba3a8563575cf authorEvan Czaplicki <info@elm-lang.org> dateTue 14 Jan 2014, 16:02 (13 years ago) parentbeabf94
1 file changed+34−12
compiler/SourceSyntax/Expression.hs+34−12
compiler/SourceSyntax/Expression.hs+34−12
@@ -1,5 +1,12 @@
11{-# OPTIONS_GHC -Wall #-}
22module SourceSyntax.Expression where
3+{-| The Abstract Syntax Tree (AST) for expressions comes in a couple formats.
4+The first is the fully general version and is labeled with a prime (Expr').
5+The others are specialized versions of the AST that represent specific phases
6+of the compilation process. I expect there to be more phases as we begin to
7+enrich the AST with more information.
8+-}
9+
310
411import SourceSyntax.PrettyPrint
512import Text.PrettyPrint as P
@@ -9,12 +16,18 @@ import qualified SourceSyntax.Pattern as Pattern
916import qualified SourceSyntax.Type as SrcType
1017import qualified SourceSyntax.Literal as Literal
1118
12−{-| This is a located expression. -}
19+---- GENERAL AST ----
20+
21+{-| This is a located expression, meaning it is tagged with info about where it
22+came from in the source code. Expr' is defined in terms of LExpr' so that the
23+location information does not need to be an extra field on every constructor.
24+-}
1325type LExpr' def = Location.Located (Expr' def)
1426
15−{-| This is a fully general expression. The compilation process will enrich
16−this data structure with additional information after the initial parse.
17−The type holes let us reflect these structural changes in the types.
27+{-| This is a fully general Abstract Syntax Tree (AST) for expressions. It has
28+"type holes" that allow us to enrich the AST with additional information as we
29+move through the compilation process. The type holes let us show these
30+structural changes in the types. The only type hole right now is:
1831
1932 def: Parsing allows two kinds of definitions (type annotations or definitions),
2033 but later checks will see that they are well formed and combine them.
@@ -42,25 +55,34 @@ data Expr' def
4255 | PortIn String SrcType.Type
4356 | PortOut String SrcType.Type (LExpr' def)
4457
58+
59+---- SPECIALIZED ASTs ----
60+
61+{-| Expressions created by the parser. These use a split representation of type
62+annotations and definitions, which is how they appear in source code and how
63+they are parsed.
64+-}
4565type ParseExpr = Expr' ParseDef
4666type LParseExpr = LExpr' ParseDef
47−type LExpr = LExpr' Def
48−type Expr = Expr' Def
4967
50−{-| Style of definitions as they are parsed. Users specify them
51−separately, and other checks will make sure they can be combined.
52−-}
5368data ParseDef
5469 = Def Pattern.Pattern LParseExpr
5570 | TypeAnnotation String SrcType.Type
5671 deriving (Show)
5772
58−{-| After checking that type annotations and definitions are all
59−valid, they can be combined.
73+{-| "Normal" expressions. When the compiler checks that type annotations and
74+ports are all paired with definitions in the appropriate order, it collapses
75+them into a Def that is easier to work with in later phases of compilation.
6076-}
61−data Def = Definition Pattern.Pattern (LExpr' Def) (Maybe SrcType.Type)
77+type LExpr = LExpr' Def
78+type Expr = Expr' Def
79+
80+data Def = Definition Pattern.Pattern LExpr (Maybe SrcType.Type)
6281 deriving (Show)
6382
83+
84+---- UTILITIES ----
85+
6486tuple :: [LExpr' def] -> Expr' def
6587tuple es = Data ("_Tuple" ++ show (length es)) es
6688