Re: Exact Print Annotations : Anchor in a SrcSpan

[Alan & Kim Zimmerman]

I agree on not re-using accidentally available structures.  But it got me
thinking that maybe the BufSpan could be something else.

I’m somewhat confused by the fact that we agreed to do it post-merge, but
> all further work has been in some other direction.
>
> My work since the merge has been on consolidating the actual use-case for
the exact print annotations, which means making sure that the (still
external) ghc-exactprint library is still able to support the existing
use-cases.  My current driver for that is porting retrie[1] to use it,
which has brought up the changes that I have been doing to GHC recently.

Once that is done, I plan to update the in-tree exact printing to match,
and then contemplate actioning plan B.

Alan

[1] https://github.com/alanz/retrie/tree/ghc-9.2
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Exact Print Annotations : Anchor in a SrcSpan

[Richard Eisenberg]

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 
> 
> 
> 
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

RE: Exact Print Annotations : Anchor in a SrcSpan

[Simon Peyton Jones via ghc-devs]

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 
simo...@microsoft.com will cease to work.  Use 
simon.peytonjo...@gmail.com instead.  (For 
now, it just forwards to simo...@microsoft.com.)

From: ghc-devs  On Behalf Of Alan & Kim Zimmerman
Sent: 28 October 2021 22:18
To: ghc-devs 
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

[1] 
https://gist.github.com/alanz/5e262599ab79138606cdfcf3792ef635


___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs