Fails to build with GHC 9.6 alpha2 about linear-base HOT 19 CLOSED

The Solo constructor has been renamed to MkSolo in 9.6 to avoid punning.

For backwards compatibility, there's a Solo pattern synonym. But pattern synonyms don't support linearity at the moment.

I'm not sure how to solve this, other than patching the code to use MkSolo.

from linear-base.

@aspiwack I think it's pretty unfriendly to tie people to one compiler version, or to anything Stack related.

from linear-base.

I try to avoid CPP pretty much like the plague. We have been using a cabal-based solution. See

from linear-base.

@Lysxia , @guibou I've released the fix on Hackage as v0.3.1.

from linear-base.

That's very strange. Any idea what might have changed? Solo x is surely linear, no?

from linear-base.

I think it worked with 9.6.0 alpha1, so that would narrow the possible cause. But I'm not familiar with the linear type implementation beyond that.

from linear-base.

Have you opened a GHC ticket?

from linear-base.

Damn @monoidal you beat me by a few seconds! The offending commit is 2463df2fe21b5b37ecada3df8c6726c534d24590. @tek you broke my library!

from linear-base.

@monoidal Good lort. Did they also break everything in Data.Semigroup and Data.Monoid and Data.Functor.Compose and even Control.Applicative?

from linear-base.

In theory I would prefer always supporting one version of GHC that is on Stackage. That being said, we can consider moving master to only supporting 9.6 and make a release for that. Otherwise we have a bit of infrastructure for version-dependent definitions. Maybe that's the best way to go, it's cheap, and conservative.

from linear-base.

@treeowl Pretty much every use of the Solo data constructor in linear-base breaks in 9.6, because it now refers to the non-linear pattern synonym. GHC's base and related modules are unaffected since they don't expose linear functions or rely on them.

Fortunately the nonpunning list/tuple proposal introduces a pattern for MkSolo only, so higher tuples will not be affected.

from linear-base.

@monoidal I'm just wondering about other base types that are traditionally punned, like Const, First, and Compose.

from linear-base.

Apologies, I misunderstood your question. Only Solo was renamed. If the other types are renamed to avoid punning, they'll also pose a problem.

I'm less worried about that though. For tuples, there was pressure to remove punning because they have special syntax and they are used often (Solo was done for consistency). For other types, the renaming is not that urgent - even if GHC gets dependent types, it'll have to support punning anyway.

from linear-base.

That's a relief. While I admit it makes sense, I've never been a big fan of the MkName convention. I believe I first saw it in Idris 1; do you happen to know where it came from originally, or how it reached Haskell?

from linear-base.

I don't know the original source. The first GHC commit from 1996 already defines data TCE = MkTCE (UniqFM TyCon).

from linear-base.

This seems easy to fix while remaining compatible with old GHCs.

Otherwise we have a bit of infrastructure for version-dependent definitions.

I don't know about what infrastructure you already have, but just to give a concrete solution, I'm partial to CPP:

#if __GLASGOW_HASKELL__ < 906
#define MkSolo Solo
#endif

from linear-base.

I try to avoid CPP pretty much like the plague.

Out of curiosity, is the rationale documented somewhere?

from linear-base.

There's a Tweag blogpost: https://www.tweag.io/blog/2019-06-27-cpp-considered-harmful/

from linear-base.

I've made a very quick shim at #438 . I… uh… only need to test it with 9.6…

from linear-base.