
I don't remember the details precisely, but I do know that the BufSpan was added to allow for reliable comparisons of SrcSpans in the presence of #line pragams. I've included Vlad, who is the resident expert on this aspect of locations. My instinct is to lean against repurposing the existing slot just because it happens to fit, unless there is a semantic argument for why the Maybe BufSpan and the Anchor represent the same underlying concept. Richard
On Oct 28, 2021, at 5:18 PM, Alan & Kim Zimmerman
wrote: 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
[1] https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635 https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs