<div dir="ltr"><div>Hi Vlad,</div><div><br></div><div>Note that the MR description is a little misleading and I should update it: I'm using an open type family, really. See <a href="https://gitlab.haskell.org/ghc/ghc/wikis/implementing-trees-that-grow/handling-source-locations#solution-d-example-code">the section for solution D on the wiki page</a> that shows how to extend the approach to Haddock (which needs SrcLocs, too).</div><div>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.</div><div><br></div><div>Sebastian<br></div><div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mo., 28. Okt. 2019 um 11:07 Uhr schrieb Vladislav Zavialov <<a href="mailto:vladislav@serokell.io">vladislav@serokell.io</a>>:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I care about this, and I maintain my viewpoint described in <a href="https://mail.haskell.org/pipermail/ghc-devs/2019-February/017080.html" rel="noreferrer" target="_blank">https://mail.haskell.org/pipermail/ghc-devs/2019-February/017080.html</a><br>
<br>
I’m willing to implement this.<br>
<br>
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?<br>
<br>
- Vlad<br>
<br>
> On 28 Oct 2019, at 12:31, Simon Peyton Jones via ghc-devs <<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a>> wrote:<br>
> <br>
> Friends<br>
> <br>
> As you know<br>
> <br>
>       • 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.<br>
>       • 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.<br>
>       • This wiki page outlines some choices, while ticket #15495 has a lot of discussion.<br>
>       • 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)<br>
>       • The proposal is to move to Solution D on that page; you can see how it plays out in MR !1970.<br>
>       • (I think Solutions B and C are non-starters by comparison.)<br>
> 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.<br>
> <br>
> Let’s try to converge by the end of the week.<br>
> <br>
> Thanks<br>
> <br>
> Simon<br>
> <br>
>  <br>
> <br>
>  <br>
> <br>
> _______________________________________________<br>
> ghc-devs mailing list<br>
> <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
> <a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
<br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>