Changes between Version 2 and Version 3 of Design/ExpPatFrame

Dec 10, 2018 10:54:36 PM (8 months ago)



  • Design/ExpPatFrame

    v2 v3  
    13= The ExpPatFrame Parser Refactoring
    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`.
     122=== Embedding Common Terms
     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.
     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.
     1281) Q) What are the other, besides the ones involved D5408, noticeable ambiguities that could benefit from an in-between datatype?
     130  A)There are [other] ambiguities when parsing data declarations, resolved them with an intermediate data type, too, in `D5180`.
     133  For example the following definition of `TyEl`:
     135  {{{#!hs
     136  data TyEl = TyElOpr RdrName | TyElOpd (HsType GhcPs)
     137            | TyElTilde | TyElBang
     138            | TyElUnpackedness ([AddAnn], SourceText, SrcUnpackedness)
     139            | TyElDocPrev HsDocString
     140  }}}
     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
     146  {{{#!hs
     147  data HsTerm trm
     148     = ... -- the common term constructs as in your `ExpPatFrame`
     150  data HsExpr x
     151    = TermE (HsTerm  (HsExpr x))
     152    | ... -- the other constructors specific  to expressions
     154  data Pat x
     155    = TermP (HsTerm (Pat x))
     156    | ...
     158  ... -- same for commands
     159  }}}
     161  There are different possible variations to above, but this is essentially to say
     163  HsExpr = Common Core + Other expression-specific constructs
     165  Pat = Common Core + Other pattern-specific constructs
     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)
     171  We identified the following pros and cons.
     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.
     175  Cons are that there will be one more matching to go under `TermX` constructor and such nesting has a (possibly negligible) performance impact.
    120178== Minimizing `ExpPatFrame`