Hi Vlad, Note that the MR description is a little misleading and I should update it: I'm using an open type family, really. See the section for solution D on the wiki page https://gitlab.haskell.org/ghc/ghc/wikis/implementing-trees-that-grow/handli... that shows how to extend the approach to Haddock (which needs SrcLocs, too). If I understand correctly, you're advocating solution B. If you can think of any more Pros and Cons (comparing to solution D, in particular), feel free to edit the wiki page. Sebastian Am Mo., 28. Okt. 2019 um 11:07 Uhr schrieb Vladislav Zavialov < vladislav@serokell.io>:
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@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@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