build(deps): bump LanguageExt.Core from 5.0.0-beta-34 to 5.0.0-beta-49

[dependabot]

Bumps LanguageExt.Core from 5.0.0-beta-34 to 5.0.0-beta-49.

Release notes

Sourced from LanguageExt.Core's releases.

Pipes refactor and Cofunctors

LanguageExt Pipes Background

Part of the v5 refresh was to migrate the Pipes functionality to be a proper monad-transformer (in v4 it's a transformer too, but it can only lift Eff<RT, A>, rather than the more general K<M, A> where M : Monad<M>). I completed the generalisation work a while back, but it had some problems:

For any users of pipes it was going to be a big upheaval

Obviously, v5 is a big change, but where possible I want the migrations to be quite mechanical - it wasn't going to be. That doesn't mean I shouldn't 'go for it', but I'm trying to make sure that every bit of pain a user has to go through to move from v4 to v5 is strongly justified and will lead to a better experience once migrated.

It was inconsistently named

The core type Proxy, and the derived types: Producer, Consumer, Pipe, etc. don't follow the monad-transformer naming convention of having a T suffix. Really, if they're going to be generalised for any monad then they should be called ProducerT, ConsumerT, PipeT, ...

Pipes is hard to use

This is not a new problem with v5. I made Pipes into a 1-for-1 clone of the Haskell Pipes library. Even in Haskell they can be quite hard to use as you chase alignment of generics. The desire for pipes to support: producers, pipes, clients, servers, and more seems (in hindsight) to be too greedy.

Hard to retrofit

The generalisation process wasn't working well in some areas. The Producer.merge was blocking and fixing it with the original code was challenging to say the least.

LanguageExt Pipes Refresh

So, I decided to take a step back. Instead of trying to make an exact clone of the Haskell version, I thought I'd build it from scratch in a way that's more 'csharpy', consistent, and simpler. In particular I looked at the techniques I used to refactor the IO monad (to support recursion, asynchrony, etc.) and brought them into a new Pipes implementation.

I also decided to drop support for Client, Server, Request, Response, and all of the other stuff that I suspect nobody used because they were too hard.

That means:

• There's no need for an underlying Proxy<A1, A, B1, B, M, R> interface. This was only needed to support all flavours of client, server, producer, consumer, etc.
• The base-type of all pipes related types is: PipeT<IN, OUT, M, R>
  • This is clearly easier to understand
  • A ProducerT<OUT, M, R> is simply a pipe with the input set to Unit:
    • PipeT<Unit, OUT, M, R>
  • A ConsumerT<IN, M, R> is simply a pipe with the output set to Void:
    • PipeT<IN, Void, M, R>
  • A EffectT<M, R> is simply a pipe with the input set to Unit and the output set to Void. This enclosed effect is the result of fusing producer, pipe, and consumers together:
    • PipeT<Unit, Void, M, R>

Those four types: ProducerT, PipeT, ConsumerT, and EffectT are the new simplified and, fully generalised, version of pipes.

Now that the generalised implementation follows the naming convention of having a T suffix for transformers, we can use the original names Producer, Pipe, Consumer, and Effect to provide a more specialised version that only works with Eff<RT, A> (like the original pipes).

So,

• Producer<RT, OUT, R> is (internally) a ProducerT<OUT, Eff<RT>, R>
• Pipe<RT, IN, OUT, R> is (internally) a PipeT<IN, OUT, Eff<RT>, R>
• Consumer<RT, IN, R> is (internally) a ConsumerT<IN, Eff<RT>, R>
• Effect<RT, IN, R> is (internally) a EffectT<IN, Eff<RT>, R>

... (truncated)

Commits

• See full diff in compare view

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

---

Dependabot commands and options

You can trigger Dependabot actions by commenting on this PR:

• @dependabot rebase will rebase this PR
• @dependabot recreate will recreate this PR, overwriting any edits that have been made to it
• @dependabot merge will merge this PR after your CI passes on it
• @dependabot squash and merge will squash and merge this PR after your CI passes on it
• @dependabot cancel merge will cancel a previously requested merge and block automerging
• @dependabot reopen will reopen this PR if it is closed
• @dependabot close will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
• @dependabot show <dependency name> ignore conditions will show all of the ignore conditions of the specified dependency
• @dependabot ignore this major version will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this minor version will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
• @dependabot ignore this dependency will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)