Alan
I’m way behind with this exact-print stuff and Anchors in particular.
If you and your co-workers on it are confident you know what to do, that’s great – although as ever, please document the design carefully. (I volunteer as a reader of such a design overview. I
know that a current draft exists.)
If you want a design discussion with others less closely involved then do suggest it -- probably a synchronous meeting with a tutorial element would be helpful.
thanks for working on this in such a sustained way.
Simon
PS: I am leaving Microsoft at the end of November 2021, at which point
simonpj@microsoft.com will cease to work. Use
simon.peytonjones@gmail.com instead. (For now, it just forwards to simonpj@microsoft.com.)
From: ghc-devs <ghc-devs-bounces@haskell.org>
On Behalf Of Alan & Kim Zimmerman
Sent: 28 October 2021 22:18
To: ghc-devs <ghc-devs@haskell.org>
Subject: Exact Print Annotations : Anchor in a SrcSpan
I have been updating the ghc-exactprint library for real world use cases on the about to be released GHC 9.2.1, and realised I need to be able to put an Anchor into every SrcSpan in the ParsedSource AST.
I prepared !6854 to sort it out in master and turned to the problem of GHC 9.2.1, where I had missed the boat.
And then I discovered that we have SrcSpan defined as
data SrcSpan =
RealSrcSpan !RealSrcSpan !(Maybe BufSpan)
| UnhelpfulSpan !UnhelpfulSpanReason
and the (Maybe BufSpan) is only used for attaching haddock comments after parsing.
This means there is an isomorphism between the RealSrcSpan variant and an Anchor, which I take advantage of with the code in [1], by using the Maybe to encode the AnchorOperation and the BufSpan to encode the DeltaPos.
And it struck me that perhaps we should make this a more official approach. The only problem is the detail of the BufSpan, to be able to play both roles cleanly.
Alan