Template Haskell changes to names and package keys

[Simon Peyton Jones]

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.

Very good exercise!  Looking for how an existing API is used (perhaps in a clumsy way, because of the inadequacies of the existing API) is a good guide to improving it.

e.g. If tuple names are an issue, let’s provide a TH API for getting their names!!

Simon


From: Libraries [mailto:libraries-bounces at haskell.org] On Behalf Of Michael Sloan
Sent: 02 May 2015 23:46
To: Bertram Felgenhauer
Cc: Haskell Libraries
Subject: Re: Template Haskell changes to names and package keys



On Sat, May 2, 2015 at 2:38 AM, Bertram Felgenhauer <bertram.felgenhauer at googlemail.com<mailto: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<mailto: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/20150505/d385db6c/attachment.html>