Handling source locations in HsSyn via TTG

Wed Oct 30 13:12:36 UTC 2019

> I would like to submit a solution E, which is just a variant of D (or a
meshing together of D and B), but may have different pros and cons.

I like this conceptually: No `WrapL`/`WrapX`/`XWrap`/`XRec` (the trouble to
find a fitting name already suggests that it's maybe a little too general a
concept), but rather a nicely targeted `XLoc`.

But I'm afraid that the unconditional ping-pong incurs an indirection even
if you instantiate `XLoc` to `()` all the time. I think that's a no-go,
according to the wiki page: Think of TH, which would pay needlessly.
Also it's not much better than just the old ping-pong style, where we could
always pass `noSrcLoc` instead of `()` for basically the same heap layout.

Am Mi., 30. Okt. 2019 um 14:06 Uhr schrieb Spiwack, Arnaud <
arnaud.spiwack at tweag.io>:

> I would like to submit a solution E, which is just a variant of D (or a
> meshing together of D and B), but may have different pros and cons.
>
> Keep the ping-pong style. But! Let Located take the pass as an argument.
> Now, Located would be
>
> data Located p a = L (XLoc p) a
>
> We could define XLoc p to be a source span in GHC passes, and () in
> Template Haskell.
> ------------------------------
>
> I’m not arguing in favour of E, at this point: just submitting an
> alternative. I don’t like A though: I’m assuming that if we are free to add
> the L constructor or not, it will be forgotten often. This is the sort of
> mistake which will be hard to catch before releases. It sounds like
> unnecessary risk.
>
> PS: Maybe a friendlier version of Located, in this solution E, could be
>
> data Located a p = L (XLoc p) (a p)
>
>
> On Mon, Oct 28, 2019 at 11:46 AM Richard Eisenberg <rae at richarde.dev>
> wrote:
>
>> A nice property of Solution D (and I think this is a new observation) is
>> that we could accommodate both located source and unlocated. For example:
>>
>> > data GhcPass (c :: Pass)   -- as today
>> > data Pass = MkPass Phase HasLoc
>> > data Phase = Parsed | Renamed | Typechecked
>> > data HasLoc = YesLoc | NoLoc
>> >
>> > type instance WrapL (GhcPass (MkPass p YesLoc)) f = Located (f (GhcPass
>> (MkPass p YesLoc)))
>> > type instance WrapL (GhcPass (MkPass p NoLoc)) f = f (GhcPass (MkPass p
>> NoLoc))
>>
>> I don't actually think this is a good idea, as it would mean making a
>> bunch of functions polymorphic in the HasLoc parameter, which is
>> syntactically annoying. But the existence of this approach suggests that
>> the design scales.
>>
>> Regardless of what you think of this new idea, I'm in favor of Solution
>> D. I like my types to stop me from making errors, and I'm willing to put up
>> with the odd type error asking me to write `unLoc` as I work in order to
>> avoid errors.
>>
>> Richard
>>
>> > On Oct 28, 2019, at 10:30 AM, Vladislav Zavialov <vladislav at serokell.io>
>> wrote:
>> >
>> >> Are you arguing for Solution D?  Or are you proposing some new
>> solution E?  I can't tell.
>> >
>> > I suspect that I’m arguing for Solution B, but it’s hard to tell
>> because it’s not described in enough detail in the Wiki.
>> >
>> >> Easy
>> >>
>> >>      type instance WrapL ToolPass t = ...
>> >>
>> >> What am I missing?
>> >
>> >
>> > This assumes that `WrapL` is an open type family. In this case, there’s
>> no problem. The merge request description has the following definition of
>> WrapL:
>> >
>> > type instance WrapL p (f :: * -> *) where
>> >  WrapL (GhcPass p) f = Located (f (GhcPass p))
>> >  WrapL p           f =          f p
>> > type LPat p = WrapL p Pat
>> >
>> > That wouldn’t be extensible. However, if WrapL is open, then Solution D
>> sounds good to me.
>> >
>> > - Vlad
>> >
>> >> On 28 Oct 2019, at 13:20, Simon Peyton Jones <simonpj at microsoft.com>
>> wrote:
>> >>
>> >> Vlad
>> >>
>> >> Are you arguing for Solution D?  Or are you proposing some new
>> solution E?  I can't tell.
>> >>
>> >>
>> >> | 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?
>> >>
>> >> Easy
>> >>
>> >>      type instance WrapL ToolPass t = ...
>> >>
>> >> What am I missing?
>> >>
>> >> Simon
>> >>
>> >> | -----Original Message-----
>> >> | From: Vladislav Zavialov <vladislav at serokell.io>
>> >> | Sent: 28 October 2019 10:07
>> >> | To: Simon Peyton Jones <simonpj at microsoft.com>
>> >> | Cc: ghc-devs at haskell.org
>> >> | Subject: Re: Handling source locations in HsSyn via TTG
>> >> |
>> >> | I care about this, and I maintain my viewpoint described in
>> >> |
>> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has
>> >> | kell.org%2Fpipermail%2Fghc-devs%2F2019-
>> >> | February%2F017080.html&data=02%7C01%7Csimonpj%40microsoft.com
>> %7C06c859
>> >> |
>> d8bc0f48c73cb208d75b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63
>> >> |
>> 7078540055975603&sdata=FhkqfWGXaNX%2Fz4IiCcvoVCyzVsSAlyz6Y1dxEGUjX9I%3
>> >> | D&reserved=0
>> >> |
>> >> | 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
>> >> | >
>> >> |
>> https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask
>> >> | ell.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-
>> >> | devs&data=02%7C01%7Csimonpj%40microsoft.com
>> %7C06c859d8bc0f48c73cb208d7
>> >> |
>> 5b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078540055975603&a
>> >> |
>> mp;sdata=CRYEYmjuAYYIhoAeTPbi%2FctCiWmkIjL6pKUTBgVBwo8%3D&reserved=0
>> >>
>> >
>> > _______________________________________________
>> > 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
>>
> _______________________________________________
> 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/20191030/ec367020/attachment.html>