Template Haskell changes to names and package keys

[Michael Sloan]

On Sat, May 2, 2015 at 2:38 AM, Bertram Felgenhauer <
bertram.felgenhauer at googlemail.com> wrote:

> Hi Michael,
>
> > 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.
>
> Same here.
>
> > Like Dan, I'm a little less keen on #1.  Here's why:
> >
> [...]
> >
> > * 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.
>
> Did you find any uses where an existing PkgName is reused to construct
> a new name? I believe this would be an important data point for deciding
> whether renaming the constructor is a good idea or not. Basically I'm
> asking whether the majority of uses of PkgName "out in the wild" right
> now is correct or incorrect.
>

I didn't search for that, since I was searching for explicit uses of
PkgName.  The results for NameG are pretty interesting, though:

https://github.com/search?l=haskell&q=NameG&type=Code&utf8=%E2%9C%93

It seems like most of the results are either `Lift`ing a PkgName or
re-using a PkgName from another name.  However, there are a fair number of
uses which explicitly construct the name, though.  In particular, there are
a fair number of usages of this to generate references to the tuple
constructors in GHC.Prim.

Interestingly, these usages of (mkPkgName "ghc-prim") don't have version
numbers at all.  This implies that the behavior is to select the version of
the package which is currently being used.

Considering how much more convenient this is than manually looking up
package names, I'm strongly in favor of keeping PkgName and its current
behavior, and extending it to handle package keys.  Ideally, also
documenting the different formats it expects.  In particular, "name",
"name-version", and "name-version-key" (I'm guessing).

The issue here is that we may be linking against two different packages
which are named the same thing, right?  This was always a possibility, and
having package keys just makes it so that we need the ability to
disambiguate packages beyond version numbers.

So, how about for this rare-ish case where there we're linking against two
different versions of the foo package, and the TH manually generates a
(PkgName "foo"), we generate an ambiguity error.

If we force users to search for and specify fully unambiguous package names
then that pushes the boilerplate of package selection out to TH usage.  It
seems like pretty much everyone will want "select the version of the
package that I'm using."  That said, I'm also in favor of adding the
function mentioned in #2, for those cases where the default isn't
sufficient (I'm anticipating very few of these).

-Michael

Cheers,
>
> Bertram
> _______________________________________________
> Libraries mailing list
> Libraries at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/libraries
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/libraries/attachments/20150502/c193e066/attachment.html>