<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 1, 2015 at 5:48 PM, Edward Z. Yang <span dir="ltr"><<a href="mailto:ezyang@mit.edu" target="_blank">ezyang@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> Being able to get all the packages that have a particular name sounds<br>
> good!  Note that if "-hide-package" / "-hide-all-packages" is used, I<br>
> wouldn't want those packages in the results.<br>
<br>
</span>This is not entirely clear; you could imagine a package also coming with<br>
an 'exposed' bit, so you could filter for exposed/not exposed pacakges.<br>
<span class=""><br>
> Like Dan, I'm a little less keen on #1.  Here's why:<br>
><br>
> * PkgName is in the internal "Language.Haskell.TH.Syntax" module<br>
><br>
> * It isn't actually documented what it means, so it's meaning can be freely<br>
> bent.  There's no guarantee that you should be able to generate them.<br>
><br>
> * I couldn't find any examples of its usage that would be broken by this<br>
> new semantics.  I've done a search on github[1] to find usages of PkgName,<br>
> and I only found one use[2] that uses PkgName which would be affected by<br>
> this change.  This example is in the TH lib itself, and so would hopefully<br>
> be fixed by this change.<br>
><br>
> On the other hand, since it's rarely used, such an API breakage wouldn't be<br>
> that impactful, so it's not that big of a deal.<br>
<br>
</span>Actually, this proposal was prompted by two separate reports of<br>
breakage:<br>
<br>
    <a href="https://github.com/ekmett/lens/issues/496" target="_blank">https://github.com/ekmett/lens/issues/496</a><br>
    <a href="https://ghc.haskell.org/trac/ghc/ticket/10279" target="_blank">https://ghc.haskell.org/trac/ghc/ticket/10279</a><br>
<br>
So, like it or not, people seem to be depending on this API, which means<br>
it's worth at least discussing a little when we change it :)<br></blockquote><div><br>Hmm, while that is a rather exotic circumstance (building a stage1 cross compiler), it is legitimate.  Also, it occurs to me that one benefit of breaking compatibility is not only for old code, but also future code.  This will ensure that authors of new TH code are aware of this distinction if the attempt to build on older GHCs.</div><div><br>So, I don't really feel strongly about it, and changing PkgKey seems fine.  TH doesn't need to be the stablest of APIs.<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Cheers,<br>
Edward<br>
</blockquote></div><br></div></div>