mkLensName hack incompatible with backpack / packages keys

[luite]

GHC HEAD (7.9) uses package keys instead of version numbers in package names.

Using names from mkLensName makes GHC panic. While GHC probably shouldn't do that, it looks like this approach isn't usable anymore, or at least requires some modifications.

See https://ghc.haskell.org/trac/ghc/ticket/9745

[ekmett]

@ezyang Any idea how to fix this?

[ezyang]

Well, you could stop flagrantly violating abstraction barriers ;)

If it isn't providing it already, the Paths module should provide the assigned package key, so you can just use that directly rather than jerry-rigging it from the version.

[ekmett]

I could stop flagrantly violating abstraction barriers, but then I have to give up on stage1 support for lens. Given that there are a number of distributions that rely upon that I am not in a hurry to do so. ;)

The problem is ''Foo doesn't work without TemplateHaskell which doesn't work without stage2.

I don't particularly want to turn off large portions of the API when on certain platforms with certain flags, because detecting the stage is a mess, and not doing something leads to a situation where half a dozen linux distros all home-grow their own broken subsets of lens just to avoid TH.

[ekmett]

It appears Paths_foo only exposes the version, not the hash.

[ezyang]

OK, I'll file a feature request in Cabal to add that.

[ekmett]

Then I suppose what we'll have to do is only support the latest and greatest cabal for GHC 7.9+ when that goes through.

[ezyang]

Well, you were going to need the latest version of Cabal for GHC 7.9+ anyway, so nothing lost there.

[ekmett]

Fair enough. =)

On Fri, Oct 31, 2014 at 6:00 PM, Edward Z. Yang notifications@github.com
wrote:

Well, you were going to need the latest version of Cabal for GHC 7.9+
anyway, so nothing lost there.

—
Reply to this email directly or view it on GitHub
#496 (comment).

[ekmett]

Note: We can't make the lens itself depend on cabal >= 1.22, our support window is too large, we guarantee support for 3-4 GHC versions along with the cabal version that ships with them, so you can't tie generating the actual extra member to the cabal version bound check in the .cabal file without killing us.

[dcoutts]

I'd much rather lens find some other proper solution to the issue of limited TH support in stage1 rather than us force package key to be exposed from Cabal, when it's something that's supposed to be private to ghc (with limited knowledge in Cabal). Given that lens can't use the workaround we're providing anyway...

[ekmett]

Assuming you can't build GHC 7.10+ without cabal >= 1.22 then we can just check __GLASGOW_HASKELL__ >= 710 and switch to using the packageKey, so we can use the solution put forth here, as long as the presence of the packageKey in the Paths_foo file isn't a thing we only get based on the cabal-version dependency in the cabal file.

[ezyang]

I'm going to take this opportunity to ask the dumb question: why doesn't lens put its TH functionality in another package?

[ekmett]

Because it means every user has to pick up a second dependency, and 2
import lines to do everything, or we have to pick up a bizarre 3 package
design, because lens uses itself inside of its own template haskell
component heavily.

The cost is borne by the users.

This justification is similar to:
https://github.com/ekmett/lens/wiki/faq#lens-core

A large part of the 'zen' of lens is that you import Control.Lens and set
to work, unlike with say data-lens where you have to add 3 packages and
import 3 things to even write the first line of code.

On Mon, Nov 3, 2014 at 5:27 PM, Edward Z. Yang notifications@github.com
wrote:

I'm going to take this opportunity to ask the dumb question: why doesn't
lens put its TH functionality in another package?

—
Reply to this email directly or view it on GitHub
#496 (comment).

[glguy]

Resolved by 45cd21b

To be released in 4.7