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 > <[email protected]> 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 > [email protected] > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs _______________________________________________ ghc-devs mailing list [email protected] http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
