Changes between Version 2 and Version 3 of Design/ExpPatFrame


Ignore:
Timestamp:
Dec 10, 2018 10:54:36 PM (8 months ago)
Author:
Shayan-Najd
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • Design/ExpPatFrame

    v2 v3  
     1[[PageOutline(1-3)]]
     2
    13= The ExpPatFrame Parser Refactoring
    24
     
    118120Imagine we're parsing a `HsExpr GhcPrePs` – it will contain `LHsLocalBinds GhcPrePs` and `LPat GhcPrePs`. Converting them to `GhcPs` is extra code and extra runtime – we don't want that. Instead, in `ExpPatFrame` we store `LHsLocalBinds GhcPs` and `LPat GhcPs` in corresponding places. Therefore, `ExpPatFrame` does not constitute a proper pass: we pre-parse little fragments that store `GhcPs` subtrees and then convert these fragments to `HsExpr GhcPs`, `HsPat GhcPs`, or `HsPat GhcPs`.
    119121
     122=== Embedding Common Terms
     123
     124We (simonpj, int-index, goldfire, and I (Shayan)) had an email discussion to overview the design space and the results are documented as the following.
     125
     1260) The process of parsing includes two subprocesses of parsing ambiguous bits into small in-between datatypes (in linear time), and then resolving ambiguities and converting (in linear time) from the in-between datatypes to the relevant `HsSyn` types of `GhsPs` pass.
     127
     1281) Q) What are the other, besides the ones involved D5408, noticeable ambiguities that could benefit from an in-between datatype?
     129
     130  A)There are [other] ambiguities when parsing data declarations, resolved them with an intermediate data type, too, in `D5180`.
     131 
     132
     133  For example the following definition of `TyEl`:
     134
     135  {{{#!hs
     136  data TyEl = TyElOpr RdrName | TyElOpd (HsType GhcPs)
     137            | TyElTilde | TyElBang
     138            | TyElUnpackedness ([AddAnn], SourceText, SrcUnpackedness)
     139            | TyElDocPrev HsDocString
     140  }}}
     141
     1422) I proposed to consider the possibility of defining a common core "pre-expression" where expressions, patterns and commands are made of.
     143   It would possibly help to define the three as a composition of the common core and the bits specific them.
     144   Then we can have declarations similar to
     145
     146  {{{#!hs
     147  data HsTerm trm
     148     = ... -- the common term constructs as in your `ExpPatFrame`
     149
     150  data HsExpr x
     151    = TermE (HsTerm  (HsExpr x))
     152    | ... -- the other constructors specific  to expressions
     153
     154  data Pat x
     155    = TermP (HsTerm (Pat x))
     156    | ...
     157
     158  ... -- same for commands
     159  }}}
     160
     161  There are different possible variations to above, but this is essentially to say
     162
     163  HsExpr = Common Core + Other expression-specific constructs
     164
     165  Pat = Common Core + Other pattern-specific constructs
     166
     167  (Notice one can split things up all the way to achieve one
     168  datatype-per-constructor, but a couple of years ago we've found it
     169  overkilling)
     170
     171  We identified the following pros and cons.
     172
     173  Pros are that there will be fewer constructors, and more importantly, parts that look the same may be pretty-printed (or possibly renamed, desugared, ...) the same.
     174
     175  Cons are that there will be one more matching to go under `TermX` constructor and such nesting has a (possibly negligible) performance impact.
     176 
     177
    120178== Minimizing `ExpPatFrame`
    121179