- User Since
- Nov 19 2014, 1:59 PM (256 w, 2 d)
Dec 10 2018
(and I have updated the wiki page to summarise our email communication: https://ghc.haskell.org/trac/ghc/wiki/Design/ExpPatFrame#EmbeddingCommonTerms)
Dec 7 2018
I have taken another look, and now understand int-index's argument.
Dec 6 2018
Thanks for pointing me to this.
I have taken a quick look.
I agree this is the right place to use TTG.
In fact, I pitched TTG in Japan (HiW'16), by demonstrating a bug (now patched), caused by the very confusion of Expr and Pat, that allowed compiling a module containing only the text`boo@ooo` leading to a GHC panic :)
The other Haskell parsers,e.g. Haskell-Src-Exts (HSE), also often have a "pre-parsing" (or "mid-parsing") AST.
I am not yet sure about some details here, like what suits parsing in the presence of ambiguity best. I will take a closer look at int-index's use of FrameX tomorrow.
Nov 23 2018
[TTG: Handling Source Locations] Foundation and Pat
Nov 9 2018
We had another set of discussions through the email and decided to land this patch soon, followed up with a series of other patches that implement the same solution for the other data types and another series of patchers that make the code more idiomatic (e.g., removing the fooLPat by adding a clause to a fooPat).
Oct 16 2018
Aug 17 2018
Aug 14 2018
Aug 9 2018
Aug 2 2018
Jul 13 2018
- [TTG - SrcLocs] minor
Jul 12 2018
Apr 25 2018
All is as expected (systematic). Finally, we got rid of the old PostRN / PostTC solution using TTG.
If the performance measures are also as expected, I suggest landing this patch.
Apr 12 2018
I looked through the changes, and all seems as expected.
General question: about the choice of what to consider as an extension (both new fields and new constructors) does it follow wip/GrowableAST?
Nov 15 2017
Similar to my question on the previous TTG patch: why NoSourceText and not noExt? (If this patch is not the place to fix these, I understand)
Nov 14 2017
I have taken a quick look and added some quick comments.
Nov 6 2017
Could you update https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow to reflect the current plan? It's out of date.
I don't like the "NewT" nomenclature for the "extra" data constructor for data type T. Could it be XT?
Nov 4 2017
I have taken a look. It all seems as expected and rather mechanical. There are some bits sticking out, those that Simon and Ben commented on, that I believe are some side-effects of splitting the big patch into multiple steps: the treatment of binders sticks out that can be treated in the next step and there are some bits that can be done when we update HsExpr as well.
Sep 11 2017
Jun 1 2017
I am not sure if I really qualify as a reviewer for this.
This is a minor, yet enabling step in practice.
All is as planned and described in the wiki, and if other reviewers are fine with it, there should be no problem in landing it as soon as possible.