Template Haskell changes to names and package keys

[Michael Sloan]

On Fri, May 1, 2015 at 5:48 PM, Edward Z. Yang <ezyang at mit.edu> wrote:

> > Being able to get all the packages that have a particular name sounds
> > good!  Note that if "-hide-package" / "-hide-all-packages" is used, I
> > wouldn't want those packages in the results.
>
> This is not entirely clear; you could imagine a package also coming with
> an 'exposed' bit, so you could filter for exposed/not exposed pacakges.
>
> > Like Dan, I'm a little less keen on #1.  Here's why:
> >
> > * PkgName is in the internal "Language.Haskell.TH.Syntax" module
> >
> > * It isn't actually documented what it means, so it's meaning can be
> freely
> > bent.  There's no guarantee that you should be able to generate them.
> >
> > * I couldn't find any examples of its usage that would be broken by this
> > new semantics.  I've done a search on github[1] to find usages of
> PkgName,
> > and I only found one use[2] that uses PkgName which would be affected by
> > this change.  This example is in the TH lib itself, and so would
> hopefully
> > be fixed by this change.
> >
> > On the other hand, since it's rarely used, such an API breakage wouldn't
> be
> > that impactful, so it's not that big of a deal.
>
> Actually, this proposal was prompted by two separate reports of
> breakage:
>
>     https://github.com/ekmett/lens/issues/496
>     https://ghc.haskell.org/trac/ghc/ticket/10279
>
> So, like it or not, people seem to be depending on this API, which means
> it's worth at least discussing a little when we change it :)
>

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.

So, I don't really feel strongly about it, and changing PkgKey seems fine.
TH doesn't need to be the stablest of APIs.


> Cheers,
> Edward
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150501/b8760fcd/attachment.html>