Handling source locations in HsSyn via TTG

[Sebastian Graf]

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/handling-source-locations#solution-d-example-code>
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 at 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 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
>
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20191028/ea16dae9/attachment.html>