<div dir="ltr"><div>Agreed: it doesn't affect the heap layout, just the types. My reading of the wiki page was not that the heap indirection was the main motivation for this little enquiry, though. Rather some type annoyance things. I don't know that E is the best solution, or even a good solution: I just think it deserves to be part of this conversation.<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, Oct 30, 2019 at 2:12 PM Sebastian Graf <<a href="mailto:sgraf1337@gmail.com">sgraf1337@gmail.com</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"><div dir="ltr"><div>> 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.</div><div><br></div><div>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`.</div><div><br></div><div>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.</div><div>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.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Am Mi., 30. Okt. 2019 um 14:06 Uhr schrieb Spiwack, Arnaud <<a href="mailto:arnaud.spiwack@tweag.io" target="_blank">arnaud.spiwack@tweag.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"><div dir="ltr"><div><p style="margin:0px 0px 1.2em">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">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-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);display:block;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248) none repeat scroll 0% 0%"><span><span style="color:rgb(51,51,51);font-weight:bold">data</span> <span style="color:rgb(68,85,136);font-weight:bold">Located</span> p a = <span style="color:rgb(68,85,136);font-weight:bold">L</span> <span>(<span style="color:rgb(68,85,136);font-weight:bold">XLoc</span> <span style="color:rgb(153,0,0);font-weight:bold">p</span>)</span> a</span>
</code></pre>
<p style="margin:0px 0px 1.2em">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">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">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-family:Consolas,Inconsolata,Courier,monospace;font-size:1em;line-height:1.2em;margin:1.2em 0px"><code style="font-size:0.85em;font-family:Consolas,Inconsolata,Courier,monospace;margin:0px 0.15em;white-space:pre-wrap;overflow:auto;border-radius:3px;border:1px solid rgb(204,204,204);display:block;padding:0.5em;color:rgb(51,51,51);background:rgb(248,248,248) none repeat scroll 0% 0%"><span><span style="color:rgb(51,51,51);font-weight:bold">data</span> <span style="color:rgb(68,85,136);font-weight:bold">Located</span> a p = <span style="color:rgb(68,85,136);font-weight:bold">L</span> <span>(<span style="color:rgb(68,85,136);font-weight:bold">XLoc</span> <span style="color:rgb(153,0,0);font-weight:bold">p</span>)</span> <span>(<span style="color:rgb(153,0,0);font-weight:bold">a</span> <span 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:0px;width:0px;max-height:0px;max-width:0px;overflow:hidden;font-size:0em;padding:0px;margin:0px"></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" target="_blank">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>
_______________________________________________<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>
</blockquote></div></div>