New Hackage release for 8.10 - Polysemy

Perhaps there should be another release before "v2", because the current version doesn't build with ghc 8.10 - https://github.com/polysemy-research/polysemy/issues/336
We could also push in minor improvements from various pull requests. @TheMatten @Love Waern (King of the Homeless) ?

I guess that's a good idea :thumbs_up:

BTW, I would like to wait with v2 until https://github.com/ghc-proposals/ghc-proposals/pull/313 lands, because it will probably change the way we do effects in Haskell...

Also, there's an outdated "Unreleased changes" section at the bottom of the changelog, I suggest we update it, bump it to the top and use it. IMO it would be helpful to keep track of what changed when doing a release.

To cut this release, we must do one of the following:

1. Fix and enable loop-breaker.
2. Remove the "zero-cost abstractions" bit altogether, for the moment.

We can't lie about zero-cost abstractions.

I have no idea how to go about 1. The plugin's one of my weak spots.

@TheMatten you worked on loop-breaker, right? Or was that @Sandy Maguire 's work?

I worked on it - I guess I will try to find some time to fix it later this week

(BTW, with loopbreaker, it's technically 0-cost when -fexpose-all-unfoldings is enabled :slight_smile: )

Just curious if there's any updates on a GHC 8.10.1 release (e.g. for polysemy-plugin to fix the Ct-related build error).

let's remove the "zero-cost abstractions" bit and upload a new version?

Instead of just removing that part, maybe we could explain reasoning behind that decision

How much dark magic is behind the loopbreaker? I could offer some help

@Bolt well, thing is, as Alexis have shown, that neither of current effects libraries (including mtl) can't optimize past module boundaries (except when -fexpose-all-unfoldings is enabled, but then compiler can't keep up with big codebases like semantic) - so in long term, we probably want to remove loopbreaker altogether and switch to delimited continuation primitives (once they get accepted of course) as basis for our effects implementation, which have minimal runtime overhead

I see, so the loopbreaker is just a temporary fix and is not worth the hassle to fix it. If that's the case I agree, remove it entirely and explain the decision

And I don't think that's anything to be sad about - from runtime point of view, instead of some final transformer stack, with delimited continuations we'll run in restricted form of what could be considered ReaderT Handlers IO, which seems much more lightweight than layers and layers of transformers IMO

I'm not familiar with delimited continuations neither am capable of seeing how they help. But if this is for the best I agree with you :p

Are you familiar with Cont monad?

It provides two combinators - reset, which "delimits" continuation, and shift, which is given remaining computation that depends on it's result as a function (continuation) and returns result of whole computation in reset - example (using transformer version with IO):

evalContT do
    lift $ print 1
    x <- resetT do
        lift $ print 2
        y <- shiftT \k -> do
            lift $ k 3  -- returns 42
            lift $ k 4  -- returns 42
            pure 5
        lift $ print y
        pure 42
    lift $ print x

prints

1
2
3
4
5

You can use them to model exceptions, coroutines and all sorts of other stuff that affects control flow - and provide alternative to Tactics that has simple interface and is easier to reason about

Awesome I was not familiar with the Cont monad! But I'll read more about it :grinning_face_with_smiling_eyes: