<div dir="ltr"><div class="markdown-here-wrapper" style=""><p style="margin:0px 0px 1.2em!important">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.</p>
<p style="margin:0px 0px 1.2em!important">Keep the ping-pong style. But! Let <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Located</code> take the pass as an argument. Now, <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Located</code> would be</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="hljs language-haskell" style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248) none repeat scroll 0% 0%"><span class="hljs-typedef"><span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">data</span> <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">Located</span> p a = <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">L</span> <span class="hljs-container">(<span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">XLoc</span> <span class="hljs-title" style="color:rgb(153,0,0);font-weight:bold">p</span>)</span> a</span>
</code></pre>
<p style="margin:0px 0px 1.2em!important">We could define <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">XLoc p</code> to be a source span in GHC passes, and <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">()</code> in Template Haskell.</p>
<hr>
<p style="margin:0px 0px 1.2em!important">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 <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">L</code> 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.</p>
<p style="margin:0px 0px 1.2em!important">PS: Maybe a friendlier version of <code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline">Located</code>, in this solution E, could be</p>
<pre style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code class="hljs language-haskell" style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;padding:0px 0.3em;white-space:pre-wrap;border:1px solid rgb(234,234,234);background-color:rgb(248,248,248);border-radius:3px;display:inline;white-space:pre;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);padding:0.5em 0.7em;display:block!important;display:block;overflow-x:auto;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248) none repeat scroll 0% 0%"><span class="hljs-typedef"><span class="hljs-keyword" style="color:rgb(51,51,51);font-weight:bold">data</span> <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">Located</span> a p = <span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">L</span> <span class="hljs-container">(<span class="hljs-type" style="color:rgb(68,85,136);font-weight:bold">XLoc</span> <span class="hljs-title" style="color:rgb(153,0,0);font-weight:bold">p</span>)</span> <span class="hljs-container">(<span class="hljs-title" style="color:rgb(153,0,0);font-weight:bold">a</span> <span class="hljs-title" style="color:rgb(153,0,0);font-weight:bold">p</span>)</span></span>
</code></pre>
<div title="MDH:PGRpdj5JIHdvdWxkIGxpa2UgdG8gc3VibWl0IGEgc29sdXRpb24gRSwgd2hpY2ggaXMganVzdCBh
IHZhcmlhbnQgb2YgRCAob3IgYSBtZXNoaW5nIHRvZ2V0aGVyIG9mIEQgYW5kIEIpLCBidXQgbWF5
IGhhdmUgZGlmZmVyZW50IHByb3MgYW5kIGNvbnMuPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5L
ZWVwIHRoZSBwaW5nLXBvbmcgc3R5bGUuIEJ1dCEgTGV0IGBMb2NhdGVkYCB0YWtlIHRoZSBwYXNz
IGFzIGFuIGFyZ3VtZW50LiBOb3csIGBMb2NhdGVkYCB3b3VsZCBiZTwvZGl2PjxkaXY+PGJyPjwv
ZGl2PjxkaXY+YGBgaGFza2VsbDwvZGl2PjxkaXY+ZGF0YSBMb2NhdGVkIHAgYSA9IEwgKFhMb2Mg
cCkgYTwvZGl2PjxkaXY+YGBgPC9kaXY+PGRpdj48YnI+PC9kaXY+PGRpdj5XZSBjb3VsZCBkZWZp
bmUgYFhMb2MgcGAgdG8gYmUgYSBzb3VyY2Ugc3BhbiBpbiBHSEMgcGFzc2VzLCBhbmQgYCgpYCBp
biBUZW1wbGF0ZSBIYXNrZWxsLjwvZGl2PjxkaXY+PGJyPjwvZGl2PjxkaXY+LS0tLTxicj48L2Rp
dj48ZGl2Pjxicj48L2Rpdj48ZGl2PkknbSBub3QgYXJndWluZyBpbiBmYXZvdXIgb2YgRSwgYXQg
dGhpcyBwb2ludDoganVzdCBzdWJtaXR0aW5nIGFuIGFsdGVybmF0aXZlLiBJIGRvbid0IGxpa2Ug
QSB0aG91Z2g6IEknbSBhc3N1bWluZyB0aGF0IGlmIHdlIGFyZSBmcmVlIHRvIGFkZCB0aGUgYExg
IGNvbnN0cnVjdG9yIG9yIG5vdCwgaXQgd2lsbCBiZSBmb3Jnb3R0ZW4gb2Z0ZW4uIFRoaXMgaXMg
dGhlIHNvcnQgb2YgbWlzdGFrZSB3aGljaCB3aWxsIGJlIGhhcmQgdG8gY2F0Y2ggYmVmb3JlIHJl
bGVhc2VzLiBJdCBzb3VuZHMgbGlrZSB1bm5lY2Vzc2FyeSByaXNrLjxicj48L2Rpdj48ZGl2Pjxi
cj48L2Rpdj48ZGl2PlBTOiBNYXliZSBhIGZyaWVuZGxpZXIgdmVyc2lvbiBvZiBgTG9jYXRlZGAs
IGluIHRoaXMgc29sdXRpb24gRSwgY291bGQgYmU8L2Rpdj48ZGl2Pjxicj48L2Rpdj48ZGl2PmBg
YGhhc2tlbGw8L2Rpdj48ZGl2PmRhdGEgTG9jYXRlZCBhIHAgPSBMIChYTG9jIHApIChhIHApPC9k
aXY+PGRpdj5gYGA8YnI+PC9kaXY+" style="height:0;width:0;max-height:0;max-width:0;overflow:hidden;font-size:0em;padding:0;margin:0"></div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 28, 2019 at 11:46 AM Richard Eisenberg <<a href="mailto:rae@richarde.dev">rae@richarde.dev</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">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:<br>
<br>
> data GhcPass (c :: Pass) -- as today<br>
> data Pass = MkPass Phase HasLoc<br>
> data Phase = Parsed | Renamed | Typechecked<br>
> data HasLoc = YesLoc | NoLoc<br>
> <br>
> type instance WrapL (GhcPass (MkPass p YesLoc)) f = Located (f (GhcPass (MkPass p YesLoc)))<br>
> type instance WrapL (GhcPass (MkPass p NoLoc)) f = f (GhcPass (MkPass p NoLoc))<br>
<br>
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.<br>
<br>
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.<br>
<br>
Richard<br>
<br>
> On Oct 28, 2019, at 10:30 AM, Vladislav Zavialov <<a href="mailto:vladislav@serokell.io" target="_blank">vladislav@serokell.io</a>> wrote:<br>
> <br>
>> Are you arguing for Solution D? Or are you proposing some new solution E? I can't tell.<br>
> <br>
> 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.<br>
> <br>
>> Easy<br>
>> <br>
>> type instance WrapL ToolPass t = ...<br>
>> <br>
>> What am I missing?<br>
> <br>
> <br>
> 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:<br>
> <br>
> type instance WrapL p (f :: * -> *) where<br>
> WrapL (GhcPass p) f = Located (f (GhcPass p))<br>
> WrapL p f = f p<br>
> type LPat p = WrapL p Pat<br>
> <br>
> That wouldn’t be extensible. However, if WrapL is open, then Solution D sounds good to me.<br>
> <br>
> - Vlad <br>
> <br>
>> On 28 Oct 2019, at 13:20, Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>> wrote:<br>
>> <br>
>> Vlad<br>
>> <br>
>> Are you arguing for Solution D? Or are you proposing some new solution E? I can't tell.<br>
>> <br>
>> <br>
>> | As to merge request !1970, it isn’t good to special-case GhcPass in a<br>
>> | closed type family, making other tools second-class citizens. Let’s say I<br>
>> | have `MyToolPass`, how would I write an instance of `WrapL` for it?<br>
>> <br>
>> Easy<br>
>> <br>
>> type instance WrapL ToolPass t = ...<br>
>> <br>
>> What am I missing?<br>
>> <br>
>> Simon<br>
>> <br>
>> | -----Original Message-----<br>
>> | From: Vladislav Zavialov <<a href="mailto:vladislav@serokell.io" target="_blank">vladislav@serokell.io</a>><br>
>> | Sent: 28 October 2019 10:07<br>
>> | To: Simon Peyton Jones <<a href="mailto:simonpj@microsoft.com" target="_blank">simonpj@microsoft.com</a>><br>
>> | Cc: <a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
>> | Subject: Re: Handling source locations in HsSyn via TTG<br>
>> | <br>
>> | I care about this, and I maintain my viewpoint described in<br>
>> | <a href="https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fmail.has</a><br>
>> | <a href="http://kell.org" rel="noreferrer" target="_blank">kell.org</a>%2Fpipermail%2Fghc-devs%2F2019-<br>
>> | February%2F017080.html&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C06c859<br>
>> | d8bc0f48c73cb208d75b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63<br>
>> | 7078540055975603&sdata=FhkqfWGXaNX%2Fz4IiCcvoVCyzVsSAlyz6Y1dxEGUjX9I%3<br>
>> | D&reserved=0<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<br>
>> | closed type family, making other tools second-class citizens. Let’s say I<br>
>> | 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 <ghc-<br>
>> | <a href="mailto:devs@haskell.org" target="_blank">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<br>
>> | a situation in which GHC is merely a client of a generic HsSyn data type<br>
>> | that can be used by clients other than GHC.<br>
>> | > • One sticking point has been the question of attaching source<br>
>> | locations. We used to have a “ping-pong” style, in which very node is<br>
>> | 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<br>
>> | lot of discussion.<br>
>> | > • HEAD embodies Solution A. But it has the disadvantage that the<br>
>> | type system doesn’t enforce locations to be present at all. That has<br>
>> | undesirable consequences (eg ticket #17330)<br>
>> | > • The proposal is to move to Solution D on that page; you can see<br>
>> | 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<br>
>> | later, of course, but doing so changes a lot of code, including client<br>
>> | 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>
>> | ><br>
>> | <a href="https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask" rel="noreferrer" target="_blank">https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fmail.hask</a><br>
>> | <a href="http://ell.org" rel="noreferrer" target="_blank">ell.org</a>%2Fcgi-bin%2Fmailman%2Flistinfo%2Fghc-<br>
>> | devs&data=02%7C01%7Csimonpj%<a href="http://40microsoft.com" rel="noreferrer" target="_blank">40microsoft.com</a>%7C06c859d8bc0f48c73cb208d7<br>
>> | 5b8e895c%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637078540055975603&a<br>
>> | mp;sdata=CRYEYmjuAYYIhoAeTPbi%2FctCiWmkIjL6pKUTBgVBwo8%3D&reserved=0<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>