Handling source locations in HsSyn via TTG

[Vladislav Zavialov]

I care about this, and I maintain my viewpoint described in https://mail.haskell.org/pipermail/ghc-devs/2019-February/017080.html

I’m willing to implement this.

As to merge request !1970, it isn’t good to special-case GhcPass in a closed type family, making other tools second-class citizens. Let’s say I have `MyToolPass`, how would I write an instance of `WrapL` for it?

- Vlad

> On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs <ghc-devs at haskell.org> wrote:
> 
> Friends
> 
> As you know
> 
> 	• We are trying to use “Trees That Grow” (TTG) to move HsSyn towards a situation in which GHC is merely a client of a generic HsSyn data type that can be used by clients other than GHC.
> 	• One sticking point has been the question of attaching source locations.  We used to have a “ping-pong” style, in which very node is decorated with a source location, but that’s a bit more awkward in TTG.
> 	• This wiki page outlines some choices, while ticket #15495 has a lot of discussion.
> 	• HEAD embodies Solution A.  But it has the disadvantage that the type system doesn’t enforce locations to be present at all.   That has undesirable consequences (eg ticket #17330)
> 	• The proposal is to move to Solution D on that page; you can see how it plays out in MR !1970.
> 	• (I think Solutions B and C are non-starters by comparison.)
> If you care, please check out the design and the MR.   We can change later, of course, but doing so changes a lot of code, including client code, so we’d prefer not to.
> 
> Let’s try to converge by the end of the week.
> 
> Thanks
> 
> Simon
> 
>  
> 
>  
> 
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs