Skip to content
GitLab

handling source locations · Changes

Page history
More wiki links converted authored by Tobias Dammers's avatar Tobias Dammers
Show whitespace changes
Inline Side-by-side
implementing-trees-that-grow/handling-source-locations.md
View page @ 8f4b8cfc
......@@ -5,7 +5,7 @@
## Problem
The current design of [TTG HsSyn AST](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance) in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style.
The current design of [TTG HsSyn AST](https://gitlab.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance) in GHC stores source locations for terms of a datatype `Exp` in a separate wrapper datatype `LExp` which is mutually recursive with `Exp` such that every recursive reference to `Exp` is done **indirectly**, via a reference to the wrapper datatype `LExp` (see the example code below). We refer to this style of storing source locations as the ping-pong style.
Besides the indirection and the resulting complications of the ping-pong style, there are two key problems with it:
......@@ -14,7 +14,7 @@ Besides the indirection and the resulting complications of the ping-pong style,
For example, TH AST does not carry source locations.
1. It results in a form of conceptual redundancy: source locations are tree decorations and they belong in the extension points.
(see [TTG Guidance](https://ghc.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance))
(see [TTG Guidance](https://gitlab.haskell.org/trac/ghc/wiki/ImplementingTreesThatGrow/TreesThatGrowGuidance))
## Solutions
......