Proposal: Drop all Async variants

[louthy]

Problem

Right now language-ext has Async variants of many of the types:

Sync	Async
Option	OptionAsync
Either	EitherAsync
Try	TryAsync
TryOption	TryOptionAsync
Eff	Aff

And some types haven't yet gained either an async or a sync version:

Sync	Async
Reader
Writer
State
RWS
Fin
Validation
	Effect
	Pipe
	Consumer
	Producer

Having to create an *Async variant for every type is an unreal amount of typing and opens up many opportunities for bugs. The types in this library are all designed to work with each other also, which means lots of ToAsync and LINQ operator extensions to be written.

If I'm honest, I'm kinda sick of it, because this is all brought about by the async / await machinery of C# which 'colours' your code.

Also, really I probably shouldn't have ever built OptionAsync and EitherAsync; I fell into the trap of trying to support the C# async machinery for types that are pure data types. Also, because C# doesn't support higher-kinded generics, it meant stacking IO and data monads was impossible - so we got these variants. Right now Eff covers a lot of this functionality.

There's a big debate going on in language-development-land on whether function colouring makes sense for async code. Especially as the async / await machinery is designed to make it easy to sequence concurrent operations. If the machinery existed when C# was invented then perhaps we wouldn't have async / await, but instead have a fork operator to launch a task without waiting for its result (like fork does in Aff).

The primary argument for (async/await):

• It's declarative - and as functional programmers we like declarative code
• It's explicit - which means you're never surprised that something is running concurrently

The argument against:

• It can lead to difficulty using async and sync types together.
• Once something is async it 'expands' out to Main
• It leads to a 'code explosion' of async variants
• Boilerplate

Languages like Go have no concept of async and sync (from what I understand), if an operation is IO then the thread will be released until the IO is complete. Haskell has the IO monad which can do both sync and async operations without any declarative component (it also has a fork operator).

My Transducers prototype - which is informing how I'm going to refactor some of the core types in language-ext - has been caught in the same trap, but it's even worse in Transducers land (for boring reasons that I won't go into right now).

Even the C# team are seemingly regretting their own async / await implementation because they've been investigating adding 'green threads' to C#. They gave up for various technical reasons (see the link), not because green threads is necessarily a bad idea.

Proposal

• Deprecate *Async variants of data monads (OptionAsync and EitherAsync)
• Create a new (lightwreight) IO<A> monad that is for side-effecting computations, both synchronous and asynchronous
• Make Eff monad into a more 'heavyweight' IO monad that combines resource tracking, error handling, state management, and both synchronous and asynchronous computations.
• Create a monad transformer system that allows stacking of monads like Either and IO so analogues to EitherAsync etc. can be user-created (will also be used to create the Eff monad)
• Deprecate Aff, Try, TryAsync, TryOption, TryOptionAsync - encourage switch to Eff (or transformers)

Most usages of async/await are for concurrent IO code not for launching highly-parallel CPU threaded code. So, the focus of Eff and the IO monads should be on making that efficient and relying on fork to launch threads for CPU bound parallel operations.

Thoughts:

This sounds like a breaking change, how bad will this be?

This will force users to use the IO or Eff type to do IO, which feels right, but could lead to some major refactoring of existing code-bases. I'd want to limit that as much as possible, but in many cases it will lead to changing types from: Aff, OptionAsync, EitherAsync, Try, TryAsync, TryOption, and TryOptionAsync to Eff or monad transformer stacks. Not free, but quite mechanical. It will hurt somewhat though, this change is too large not to have an impact.

Type mapping:

From	To
Aff<RT, A>	Eff<RT, A>
Aff<A>	Eff<A>
OptionAsync<A>	OptionT<IO, A>
EitherAsync<E, A>	EitherT<E, IO, A>
Try<A>	TryT<IO, A>
TryAsync<A>	TryT<IO, A>
TryOption<A>	TryT<OptionT<IO>, A>
TryOptionAsync<A>	TryT<OptionT<IO>, A>

If there's no async / await, is this blocking?

No. The key thing to realise is that behind the scenes a lot of the async machinery is implemented with synchronous looking code. Either through wait-handles or spinning & yielding.

I propose that because IO and Eff will be for IO that we could use the SpinWait technique that's used in things like ConcurrentDictionary. and parts of the Task internals:

public static Result<A> Run(Func<CancellationToken, Task<A>> f, CancellationToken token)
{
    if (token.IsCancellationRequested) return Result<A>.Cancelled;

    // Launch the task
    var t = f(token);

    // Spin waiting for the task to complete or be cancelled
    SpinWait sw = default;
    while (!t.IsCompleted && !token.IsCancellationRequested)
    {
        sw.SpinOnce();
    }

    if (t.IsCanceled || token.IsCancellationRequested)
    {
        return Result<A>.Cancelled;
    }

    if (t.IsCompletedSuccessfully)
    {
        return Result.Value(t.Result);
    }

    if (t.IsFaulted)
    {
        return Result.Fail<A>(
            t.Exception is null 
                ? Errors.None 
                : Error.New(t.Exception));
    }

    throw new UnreachableException();
}

When you look at the internals of SpinOnce you'll see it's quite interesting (the name isn't descriptive at all!):

    private void SpinOnceCore(int sleep1Threshold)
    {
      if (this._count >= 10 && (this._count >= sleep1Threshold && sleep1Threshold >= 0 || (this._count - 10) % 2 == 0) || Environment.IsSingleProcessor)
      {
        if (this._count >= sleep1Threshold && sleep1Threshold >= 0)
          Thread.Sleep(1);
        else if ((this._count >= 10 ? (this._count - 10) / 2 : this._count) % 5 == 4)
          Thread.Sleep(0);
        else
          Thread.Yield();
      }
      else
      {
        int iterations = Thread.OptimalMaxSpinWaitsPerSpinIteration;
        if (this._count <= 30 && 1 << this._count < iterations)
          iterations = 1 << this._count;
        Thread.SpinWait(iterations);
      }
      this._count = this._count == int.MaxValue ? 10 : this._count + 1;
    }

That code is pretty hard to follow, SpinWait.WaitOne performs CPU-intensive spinning for 10 iterations before yielding. However, it doesn’t return to the caller immediately after each of those cycles: instead, it calls Thread.SpinWait to spin via the CLR (and ultimately the operating system) for a set time period. This time period is initially a few tens of nanoseconds, but doubles with each iteration until the 10 iterations are up. This ensures some predictability in the total time spent in the CPU-intensive spinning phase, which the CLR and operating system can tune according to conditions. Typically, it’s in the few-tens-of-microseconds region — small, but more than the cost of a context switch. On a single-core machine, SpinWait yields on every iteration.

If a SpinWait remains in “spin-yielding” mode for long enough (maybe 20 cycles) it will periodically yield for a few milliseconds to further save resources and help other threads progress.

That means - for IO operations that are fast - we won't have switched the context for the current thread and therefore we won't lose time context-switching. This can be highly effective as context-switching too early (just calling Thread.Yield in a spin-loop) will cost over 4000+ cycles per-yield and will lose even more time from the ensuing cache effects. For IO that does take a long time we go into a Sleep/Yield loop where we allow other tasks on this thread to take over and use the CPU resource while we're busy.

This should work pretty well for cooperative/concurrent IO operations, although it might be a little primitive. This technique will always run the continuation on the current thread, which I think for modern multi-core CPUs is probably a much better approach. But, if true deferment to another thread is needed then the Eff or IO monads can be forked which will schedule the task for another thread.

It may need something a little smarter: but as a v0.01 it'll work well enough to do some profiling.

The benefit of this is that you can run code that looks like synchronous code, but it will still yield time to the task-scheduler working on the current thread (in the same way that async / await does):

public static void Main()
{
    var result = TaskRunner<string>.Run(Long, default);
    Console.WriteLine($"{result}");
}

static async Task<string> Long(CancellationToken token)
{
    await Task.Delay(5000);
    return "Hello";
}

Obviously, all of this will be wrapped up inside the IO and Eff monads. So these moving parts won't be exposed. You will just write code as though it's synchronous and let language-ext deal with the concurrency. And if you need parallelism, just fork your Eff or IO computations.

Conclusion

This will lead to:

• A simplification of the API surface
• Less code for me to maintain
• More focus on Eff and IO as the primary IO monads
• More efficient concurrency (probably!)
• More efficient synchronous code (definitely!)
• Significantly fewer memory allocations

However, it comes with some refactoring costs (and initially lots of [Obsolete] warnings).

I want to do this, but I realise this is a biggy, so please have your say. I'm interested in support, dissent, alternative approaches, and ideas.

[aloslider]

Recently, I was stuck at combining Aff and State monads, and found that it's currently possible, but tricky to implement, so I decided to wait a while for the new release of language-ext to implement desired behaviour easier. I was hoping that your Transducers project will achieve the stuff you was trying to succeed (I guess it was about stacking monads?), but unfortunately, I guess C#'s lacks of some type-system stuff can't be tricked.

I'm not experienced enough to give any advices about library maintenance, but maybe it would be good if you split it in two parts: for example, obsolete language-ext 4.* with occasional long-time support (to complete all sync/async variants at least) and language-ext 5.* with the new way of working with Effects. It's like we have .NET(Core) and .Net Framework right now.
Personally, I respect your concerns about backward compatability and old versions support, but it isn't .NET repo or something as big. I don't mean nobody cares of this library or the changes - I just think it will not be SO bad if you introduce breaking changes, that will make it easier for you to maintain and easier for consumers to use (escpecially, if they still will be able to use older version). But I may be wrong.

By the way, there was a discussion opened in F# repo yesterday, where they are talking about similar breaking/incompatible changes problem, maybe this can help you to make a descision?

There's a big debate going on in language-development-land on whether function colouring makes sense for async code.

Noticed that too, but I'm not sure C# team will change its priorities from backward compatability to new (possibly breaking) changes and features. Also, if they will: how long will it take? Remember how long C# community waits for HKT or at least DUs support? As I understand, even F# team is afraid of making any steps further due to unforseen C# changes that may break something (recent was abstract static methods in interfaces; next one is possibly upcoming C#'s DU implementation), so they will need to change their plans and implementions to support interop with C#. And I'm not even saying about its type-system that still has some internal bugs that were done so much long ago, that it would be difficult to fix it now (IIRC it was something about with Nullable struct and its recursive field). I'm not blaming C# team - its just how they have to deal with .NET history.

[louthy]

One thing that annoyed me about .NET Core was how Microsoft just left half of the .NET community behind. They didn't have to do that and it still has repercussions today. I think that whole process was incredibly poorly managed.

I'm not looking to create two versions. There already is an area of language-ext for deprecated/obsolete code, that will just expand and I'll move the old code there so it doesn't pollute the API documentation.

Old code should still compile fine with an updated language-ext, it just will have lots of [Obsolete] warnings until the library consumer fixes up their code. That's the least worst thing for new features and deprecating old features, but it can still be hella annoying when you have to update your code because the library you depended on just changed direction without any consultation (hence this consultation).

Recently, I was stuck at combining Aff and State monads, and https://github.com/louthy/language-ext/discussions/913that it's currently possible, but tricky to implement, so I decided to wait a while for the new release of language-ext to implement desired behaviour easier. I was hoping that your Transducers project will achieve the stuff you was trying to succeed (I guess it was about stacking monads?), but unfortunately, I guess C#'s lacks of some type-system stuff can't be tricked.

That's exactly what I am solving. In the prototype is an example transformer stack:

public static class Application<Env>
{
    public static Application<Env, A> Success<A>(A value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Right(value));
    
    public static Application<Env, A> Fail<A>(Error value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Left(value));

    public static Application<Env, A> Lift<A>(ReaderT<MIO<Env>, Env, A> value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Lift(value.Morphism));
    
    public static readonly Application<Env, Env> Ask =
        Lift(ReaderT<MIO<Env>, Env>.Ask);
}

public record Application<Env, A>(EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A> Transformer) 
{
    public static Application<Env, A> Pure(A value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Right(value));

    public Application<Env, B> Map<B>(Func<A, B> f) =>
        new (Transformer.MapRight(f));

    public Application<Env, B> Select<B>(Func<A, B> f) =>
        new (Transformer.MapRight(f));

    public Application<Env, B> Bind<B>(Func<A, Application<Env, B>> f) =>
        new (Transformer.Bind(x => f(x).Transformer));

    public Application<Env, C> SelectMany<B, C>(Func<A, Application<Env, B>> bind, Func<A, B, C> f) =>
        Bind(x => bind(x).Map(y => f(x, y)));

    public Application<Env, B> BiMap<B>(Func<Error, Error> Fail, Func<A, B> Succ, Func<B>? Bottom = null) =>
        new(Transformer.BiMap(Fail, Succ));
}

This example is similar to the kind of monad-transformer stacks one might build in a Haskell project.

To the untrained eye it might not be obvious what's going on. The type Application<Env, A> is a 'domain monad', one that composes other monads into a super monad and combines the behaviours. This single value stored in the Application<Env, A> record-type is the key:

EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A> Transformer

• MIO is the monad instance for the IO type
• MReaderT is the monad instance for the ReaderT monad transformer type
• EitherT is the monad transformer for either-like behaviour

What you're looking at there is a monad-transformer stack that combines the behaviours of Either, Reader, and IO into one type called Application. It means we can then use the composed monadic types in a single LINQ expression:

    public static Application<string, string> Example =>
        from x in Application<string>.Success(100)
        from y in Application<string>.Success(200)
        from n in Application<string>.Ask
        select $"Hello {n}, the answer is: {x + y}";

And obviously any other monad-transformers that are built can be stacked in the same way.

The stacking order is actually the reverse of how they're compose, so:

So, this:

EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>

is stacked like this:

IO<Env, Reader<Env, Either<L, R>>>

Which is the same as how they work in Haskell.

If you look at the static Application<Env> class, you can see it using Right from EitherT:

    public static Application<Env, A> Success<A>(A value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Right(value));

Left from EitherT:

    public static Application<Env, A> Fail<A>(Error value) =>
        new (EitherT<MReaderT<MIO<Env>, Env>, Env, Error, A>.Left(value));

and Ask from ReaderT:

    public static readonly Application<Env, Env> Ask =
        Lift(ReaderT<MIO<Env>, Env>.Ask);

To make its own bespoke Application API surface.

I've been trying lots of different combinations of how these can be composed. I'm not 100% settled on the best approach, but I'm getting close. Writing this code is quite hard if you don't know what you're doing, which is why I want this to be generated using Source Generators (well, as much as possible). Obviously I'll also built all the monad transformer types like EitherT, OptionT, StateT, etc. so it shouldn't be too hard to get moving with it.

[glendonjklassen]

I apologize if I missed this somewhere in the repo/discussion, but is there something in the v5 pre-release that is an off-the-shelf IO/Either/State monad? I see that Eff is Readable but not Stateful. I'm relatively new to the library and FP so was trying to implement my own but the learning curve is hitting me pretty hard. I also see the above prototype but it looks like that's just in a not-for-consumption repo (even though it looks exactly like what I want).

Awesome project by the way. Thank you!

[louthy]

Not off the shelf, no. You'd need to compose the StateT, EitherT, and IO monad transformers. It should be noted that StateT limits the IO functionality in a transformer-stack (which is why Eff uses ReaderT, because it doesn't have any limitations).

The reason for this is that the MonadIO trait has a virtual method called ToIO. When you override it in a monad-transformer implementation it requires the return of an IO<A> monad. This is what it looks like for ReadeT:

public static K<ReaderT<Env, M>, IO<A>> ToIO<A>(K<ReaderT<Env, M>, A> ma) =>
    new ReaderT<Env, M, IO<A>>(env => ma.As().runReader(env).ToIO());

So, it runs the reader function (runReader), which returns the nested M monad, which it then calls ToIO on. This walks the monad-transformer stack until it reaches an IO monad. At which point the IO monad says "hey, you're looking for me" and returns itself. It's a way of unlifting the IO monad higher up the stack.

The problems occur when we try to implement this for StateT:

static K<StateT<S, M>, IO<A>> MonadIO<StateT<S, M>>.ToIO<A>(K<StateT<S, M>, A> ma) =>
    new StateT<S, M, IO<A>>(env => ma.As().runState(env).ToIO());

We get the following error:

Cannot convert expression type 'K<M,IO<(A Value, S State)>>' to return type 'K<M,(IO<A> Value, S State)>'

The problem is that StateT returns a tuple of (A, S) (holding the bound value and the updated state). Whereas ReaderT only returns A. So, the only way to implement ToIO successfully would be to drop the S and just return the A.

That may be OK for certain use-cases, but from a purist point-of-view, we're not upholding the contract of a state-monad, making it unsound. We're literally throwing the state away.

The reason all this matters is because the IO prelude, module, and extension-methods all heavily use ToIO and MapIO:

public static virtual K<M, B> MapIO<A, B>(K<M, A> ma, Func<IO<A>, IO<B>> f) =>
    M.ToIO(ma).Bind(io => M.LiftIO(f(io)));

Which also uses ToIO by default!

So, the ability to do IO in a StateT transformer is limited, forcing you to manually unlift for more complex IO use-cases.

What you can do though is build your own. These limitations are due to the rules that the monad-transformers need to follow to have robust type-composition, but you can manually compose and get the behaviour needed. Part of the major refactor that is v5 of language-ext is to bring in the traits that guide you to implement types like 'a stateful IO monad with alternative values'.

For example. We can create a new type called StateEff:

public record StateEff<S, E, A>(Func<EnvIO, S, Either<E, (S State, A Value)>> runStateEff)
    : K<StateEff<S, E>, A>
    where E : Error;

This has S for state, E for an alternative value and will support IO (although I've left the IO monad out of this definition). You'll see why in a second:

public static class StateEff
{
    public static StateEff<S, E, A> As<S, E, A>(this K<StateEff<S, E>, A> ma) 
        where E : Error =>
        (StateEff<S, E, A>)ma;
    
    public static IO<Either<E, (S State, A Value)>> Run<S, E, A>(
        this K<StateEff<S, E>, A> ma, S initialState) 
        where E : Error =>
        IO.lift(envIO => ma.As().runStateEff(envIO, initialState));
}

This has the As downcast extension and the Run extension. The Run extension wraps the runStateEff Func in an IO.lift call. So, we can do IO stuff anywhere we like without having to have any actual IO monad carried through. We just wrap the invocation which is the same as saying "everything the StateEff does is IO".

Next we create the trait-implementation type:

public class StateEff<S, E> :
    Monad<StateEff<S, E>>,
    Stateful<StateEff<S, E>, S>,
    Choice<StateEff<S, E>>
    where E : Error 
{
    static K<StateEff<S, E>, B> Monad<StateEff<S, E>>.Bind<A, B>(
        K<StateEff<S, E>, A> ma,
        Func<A, K<StateEff<S, E>, B>> f) =>
        new StateEff<S, E, B>(
            (eio, state) =>
                ma.As().runStateEff(eio, state) switch
                {
                    Either.Right<E, (S State, A Value)>(var (s, v)) =>
                        f(v).As().runStateEff(eio, s),

                    Either.Left<E, (S State, A Value)>(var e) =>
                        Left(e)
                });

    static K<StateEff<S, E>, B> Functor<StateEff<S, E>>.Map<A, B>(Func<A, B> f, K<StateEff<S, E>, A> ma) =>
        new StateEff<S, E, B>(
            (eio, state) =>
                ma.As().runStateEff(eio, state) switch
                {
                    Either.Right<E, (S State, A Value)>(var (s, v)) =>
                        Right((s, f(v))),

                    Either.Left<E, (S State, A Value)>(var e) =>
                        Left(e)
                });

    static K<StateEff<S, E>, A> Applicative<StateEff<S, E>>.Pure<A>(A value) =>
        new StateEff<S, E, A>((_, s) => Right((s, value)));

    static K<StateEff<S, E>, B> Applicative<StateEff<S, E>>.Apply<A, B>(
        K<StateEff<S, E>, Func<A, B>> mf,
        K<StateEff<S, E>, A> ma) =>
        new StateEff<S, E, B>(
            (eio, state) =>
                mf.As().runStateEff(eio, state) switch
                {
                    Either.Right<E, (S State, Func<A, B> Value)>(var (s1, f)) =>
                        ma.As().runStateEff(eio, s1) switch
                        {
                            Either.Right<E, (S State, A Value)>(var (s2, x)) =>
                                Right((s2, f(x))),

                            Either.Left<E, (S State, A Value)>(var e) =>
                                Left(e)
                        },

                    Either.Left<E, (S State, Func<A, B> Value)>(var e) =>
                        Left(e)
                });

    static K<StateEff<S, E>, Unit> Stateful<StateEff<S, E>, S>.Put(S value) =>
        new StateEff<S, E, Unit>((_, _) => Right((value, unit)));

    static K<StateEff<S, E>, Unit> Stateful<StateEff<S, E>, S>.Modify(Func<S, S> modify) =>
        new StateEff<S, E, Unit>((_, state) => Right((modify(state), unit)));

    static K<StateEff<S, E>, A> Stateful<StateEff<S, E>, S>.Gets<A>(Func<S, A> f) =>
        new StateEff<S, E, A>((_, state) => Right((state, f(state))));

    static K<StateEff<S, E>, A> Choice<StateEff<S, E>>.Choose<A>(K<StateEff<S, E>, A> fa, K<StateEff<S, E>, A> fb) =>
        new StateEff<S, E, A>(
            (eio, state) =>
                fa.As().runStateEff(eio, state) switch
                {
                    Either.Right<E, (S State, A Value)> succ =>
                        succ,

                    Either.Left<E, (S State, A Value)> =>
                        fb.As().runStateEff(eio, state)
                });

    static K<StateEff<S, E>, IO<A>> MonadIO<StateEff<S, E>>.ToIO<A>(K<StateEff<S, E>, A> ma) =>
        new StateEff<S, E, IO<A>>(
            (eio, state) =>
                ma.As().runStateEff(eio, state) switch
                {
                    Either.Right<E, (S State, A Value)>(var (s, v)) =>
                        Right((s, IO.pure(v))),

                    Either.Left<E, (S State, A Value)>(var e) =>
                        Left(e)
                });

    static K<StateEff<S, E>, A> MonadIO<StateEff<S, E>>.LiftIO<A>(K<IO, A> ma) => 
        new StateEff<S, E, A>(
            (eio, state) => 
            {
                try
                {
                    return Right((state, ma.As().Run(eio)));
                }
                catch (Exception e)
                {
                    // TODO: Decide how to convert an Exception to `E` -- this is bespoke to your code
                    //       But if you derive your `E` type from `Error` then you'll find it's easier
                    throw new NotImplementedException();
                }
            }
        );
}

It implements Monad, Stateful, and Choice traits (this list can be extended of course).

The key thing to note is we're able to make good decisions in the ToIO and LiftIO functions where we couldn't before. We can do this because we know what the whole stack looks like.

And that's it. The type will work just like the Eff monad or any other. You can lift IO behaviours into it, use things like Repeat, Retry, Post or any of the general IO behaviours and it will just work.

One thing to note is that this will all be using the general K<StateEff<S>, A> extensions. So, if you want more concrete methods (using StateEff<S, A>) then you need to add them manually. Take a look at the CardGame sample and how the Game<A> monad is implemented. You'll see lots of functions that look like this:

    public Game<B> Map<B>(Func<A, B> f) =>
        this.Kind().Map(f).As();

That maps the concrete type to the general K type with Kind(), it then calls the already existing extensions, and then downcasts back to the concrete type after using As(). So, these functions are all just wrappers that go to the existing generic functionality.

All of that is optional, but it makes working with bespoke monadic types a little easier.

If all of these concepts are blowing your mind right now and it seems insanely complex and confusing then it's worth working through my "Higher kinds in C# with language-ext" series on my blog. All of these concepts are discussed.

I may well add a type like this to language-ext in the future. But it's taken me nearly a year to get to this point with the v5 beta, so I'm not really thinking about any new types right now. My main focus is the fix any outstanding issues and to get the documentation up-to-scratch.

Hope that helps.

PS. It's probably better to raise new questions as a separate Discussion rather than continue in this thread.

[glendonjklassen]

Thank you for the comprehensive answer! I'll copy my question into a new discussion if that would help others.

[timmi-on-rails]

Dead-lock

Will there be a RunAsync method for the Eff<> type?
Because the proposed sync Run implementation can/will lead to a dead-locks in a WPF App (or in general, if the syncronization context is set).

Here is the example code, that I tested:

private void Button_Click(object sender, RoutedEventArgs e)
{
    Run(_ => DelayReturn("hello"), default);
}

private async Task<T> DelayReturn<T>(T value)
{
    await Task.Delay(1000);
    return value;
}

[louthy]

Will there be a RunAsync method for the Eff<> type?

Yes, there will be. I haven't decided on the best approach to dealing with different SynchronizationContexts yet (perhaps leveraging the runtime traits); but there will be a way to avoid the common deadlock problems.

[dirkil]

Just to add my two cents...

I would welcome the change, as I recently encountered difficulties when combining synchronous and asynchronous methods with LanguageExt. At the same time, I must confess that my codebase affected by this issue is not extensive, so it's probably easier for me to advocate for the change.

Essentially, I believe that from a neutral standpoint, it's a no-brainer to appreciate the simplicity of dealing with an Eff that is well-designed to work with both sync and async. If I had a large codebase, I would need to assess the effort required for adaptation. From what I can see, it could be quite a bit of work, but probably something that is rather straightforward. So, yes, there is a cost, but I think the benefits you'll gain are quite substantial.

[louthy]

Thank you for the feedback 👍

[StefanBertels]

Proposed change sounds great!

I currently use Nito.AsyncEx.AsyncContext.Run() to run some async code from sync code -- to avoid dead locks.
I expect the "built-in variant" will make mixing of async/sync much less pain and result in better code.

BTW: Here is another interesting example of SpinWait use in .NET runtime.
https://github.com/dotnet/runtime/blob/main/src/libraries/System.IO.Pipes/src/System/IO/Pipes/NamedPipeClientStream.cs

[louthy]

I currently use Nito.AsyncEx.AsyncContext.Run() to run some async code from sync code -

It's the opposite issue. It's sync code that needs to be called from async code. I need the sync code to not block. After a bit of testing with a simple WPF app it was relatively easy to wrap the existing SpinWait looping Run function in a RunAsync function, which can then be awaited as normal.

So for anyone running the new IO<RT, E, A>, IO<E, A>, Eff<RT, A>, or Eff<A> from an STA app then you merely have to await the associated RunAsync methods, rather than the synchronous Run methods

BTW: Here is another interesting example of SpinWait use in .NET runtime.

Indeed! Retry backing off loops seems to be a off use of this, but I guess they know what they're doing :D

[timmi-on-rails]

I had a quick look at your code. If I am not mistaken, then you simply wrap the sync code in Task.Run.
I assume what happens is, that the code (inside DelayReturn) in my example earlier (#1269 (comment)) would get executed on the task pool, instead of the UI thread.
In WPF it is important, that certain code runs on the UI thread.
Am I wrong about the executing thread? Have you checked?

[louthy]

I tested it and it works fine (I'm on my Linux environment atm, without access to my test app, but I'll post it the next time I log into Windows).

The code inside the button-handler runs in the UI thread as expected - the effect, when RunAsync'd will run on the task-pool. You won't be able to use the IO\Eff to update the state of the UI from within the effect - but you can await the result and then update your UI.

My test app looks similar to this for the button hander:

button_handler(...)
   get_state_you_care_about_from_the_UI
   await_your_IO_operation (RunAsync)
   update_your_UI_state

It's been a good 20 years, or maybe even more, since I've worked with an STA based application. I think if it's desirable that an IO monad directly updates the UI in the UI thread (that is, it can't await the result and must do the update during the IO operation) then I'd probably prefer a messaging approach than try to drag the machinery of STAs into Eff/IO.

However, if there are cunning alternatives to this approach then I'm open to suggestions. The result must be elegant and easy to consume though, otherwise no-one will use it.

[louthy]

btw, if you have scenarios where this approach might break your existing WPF code. I'd definitely appreciate a gist or example WPF app that exposes those scenarios for my testing 👍

[timmi-on-rails]

I forgot, that the situation is currently the same with Aff<>.
Running a UI Update inside Aff<> is not guaranteed to run on UI Thread, since there is .ConfigureAwait(false) involved when combining multiple Aff<>.
So I guess it is not a breaking change anyway.

[louthy]

For anyone who's interested in following the progress of this, it's all in the v5-transducers branch. I'm getting close to finishing the IO<RT, E, A> monad (the monad that the other IO monads will be built from).

I've written a lot of code in the past few weeks and not run any of it, so there's plenty of testing I need to do. But just thought I'd test out one of the major benefits of the Transducer based monads: they support infinite recursion without blowing the stack!

This example shows that in action:

static void Main(string[] args) =>
    infiniteLoop(1).Run(new MinimalRT());

static IO<MinimalRT, Error, Unit> infiniteLoop(int value) =>
    from _ in writeLine($"{value}")
    from r in infiniteLoop(value + 1)
    select unit;

This will loop forever, yet the stack never gets more than about 10 functions deep at any one time. This is a major feature that I'm very excited about, because this is a really common way that functional developers write their code and can lead to much more elegant solutions.

[timmi-on-rails]

Try Replacement

You want to deprecate Try and encourage Eff instead.
Although Try is implemented as a delegate, it was never supposed to be used for IO, so the transition is not clear to me.

Let's take the following example:

Try<int> Divide(int a, int b)
    => Try(() => a / b);
...
var result = Divide(5, 0).Invoke();

Should I use Eff instead? But it is not IO...
Another non-lazy replacement could be:

Either<Exception, int> Divide(int a, int b)
{
    try
    {
        return a / b;
    }
    catch(Exception e)
    {
        return e;
    }
}

Or perhaps with utility:

Either<Exception, T> Try<T>(Func<T> f)
{
    try
    {
        return f();
    }
    catch(Exception e)
    {
        return e;
    }
}

Either<Exception, int> Divide(int a, int b)
    => Try(() => a / b);

[louthy]

If you actually think about what Try is, it's there to catch exceptional errors. What creates exceptional errors? Yep, talking to the outside world for when things go wrong: like a file missing, etc. So Try is IO in most circumstances. Eff<A> represents operations that have side-effects, throwing exceptions is a side-effect. You can think of its internal thunk as being Unit -> Error | A, which makes it isomorphic to Try, so having two types do the same thing is maintenance effort I can well do without.

Your first example, a divide-by-zero exception is a perfect example of what should be a non-exceptional error. It is entirely expected that dividing by zero would fail. So, we should be representing that in a better way: Option<float> Divide(float x, float y) would be a better function.

The operators are of course problematic when they're not total. This is a hole in C# really.

It is, of course, unfortunate that C# libraries use exceptional errors for everything whether it is IO or not. But exceptions are side-effects and so I don't have an issue with Eff being their monadic representative.

One thing I probably will add though is a TryT monad-transformer. For those that reeeeally want Try then you can lift the identity monad into it to create a Try monad. You can see this technique in action in my prototype, there's an EitherT monad transformer which I use with the Identity monad to create Either

[timmi-on-rails]

Side note, for float the option-return function signature leaves a bit room for interpretation, because e.g. 5.0f/0.0f does not throw and evaluates to Infinity or NaN.

[louthy]

@timmi-on-rails re: cross-thread synchronisation...

I have added support for the internal state of the transducers to track the SynchronizationContext. And added a HasSyncContext trait for the runtimes.

That means the SynchronizationContext context can be grabbed from the runtime when an IO or Eff operation starts (even the non-runtime versions of IO and Eff will use the MinimalRT internally.

This then supports the new PostTransducer which can run a wrapped transducer in the captured SynchronizationContext.

The final outputted value of wrapped transducer is then passed back to the original SynchronizationContext for it to continue its journey.

I am yet to fully test this, but it should mean that running anything on the UI thread will just mean wrapping your Eff or IO in post() call.

    from x in regularThreadOp1
    from r in post(uiThreadOp1)
    from y in regularThreadOp2
    select x + r + y;

Open to thoughts on this approach.

[louthy]

There's a new WPF test-app in the v5-transducers branch.

The app features a button and a timer.

The timer updates the text of the button every millisecond. Clicking on the button resets the text. It tests the post functionality I mentioned in the previous comment.

The timer is an infinite loop that updates the count, sets the button-text, and sleeps the thread until the next tick...

IO<MinimalRT, Error, Unit> tickIO =>
    from _1 in modifyCount(x => x + 1)
    from _2 in post(setButtonText(CounterButton, $"{count}"))
    from _3 in waitFor(1)
    from _4 in tail(tickIO)
    select unit;

You'll notice that if you drag the window around, it doesn't lock up, so the sleep-delay is not on the UI thread; but it also updates the button, which must be on the UI thread. So that proves it all works nicely.

waitFor is a lifted asynchronous function - demoing the ideas behind this proposal...

IO<MinimalRT, Error, Unit> waitFor(double ms) =>
    liftIO(async token => await Task.Delay(TimeSpan.FromMilliseconds(ms), token));

NOTE: The accuracy of Task.Delay is abysmal, but it doesn't matter for this demo.

The tickIO effect is simply launched in the MainWindow constructor:

// Start the ticking...
ignore(tickIO.RunAsync(runtime));

The button-click resets the value and updates the button:

IO<MinimalRT, Error, Unit> buttonOnClickIO =>
    from _1 in resetCount
    from _2 in post(setButtonText(CounterButton, $"{count}"))
    select unit;

The Window button click handler launches the buttonOnClickIO effect:

async void ButtonOnClick(object? sender, RoutedEventArgs e) =>
    ignore(await buttonOnClickIO.RunAsync(runtime));

The setButtonText function is quite simple also:

/// <summary>
/// Helper IO for setting button text 
/// </summary>
static IO<MinimalRT, Error, Unit> setButtonText(Button button, string text) =>
    lift(action: () => button.Content = text);

But, obviously calling this without wrapping the call in post will fail.

So, what do we see in this demo:

• Transducer based IO monad
• Asynchronous code being lifted into the IO monad (the whole point of this proposal)
• Synchronous code being lifted into the same IO monad type
• The ability to dispatch the IO effect to the task-pool
• Easy synchronisation, using post, with the UI thread of a WPF app (or any STA application)
• Infinite recursion without blowing up the stack or creating space-leaks (memory leaks)

Quite a lot for a small demo 👍

[timmi-on-rails]

Wow, cool demo.

More remarks:

1. Another dead-lock reason (I once read about) is thread-pool exhaustion (like here https://medium.com/rubrikkgroup/understanding-async-avoiding-deadlocks-e41f8f2c6f5d).
   I wonder if that is an issue here, since you spin up one Task for each RunAsync (to run the spin-wait loop non-blocking).
   On the other hand, RunAsync is probably called only once per user action/request.
   I guess internally, when combining IO (like monadic bind, etc.) you are not using Task.Run

2. Faking an async API with Task.Run is considered bad practise (no performance gain, if it is not naturally async). Atleast that is what I remembered when reading about those topics. (like here https://blog.stephencleary.com/2013/11/taskrun-etiquette-examples-dont-use.html).

[seungyongshim]

Excuse, me.
I have recognized that there are significant and disruptive changes between versions 4 and 5.

Could you write code considering Microsoft's best practices?
You can refer to the following link for guidance: Avoid Blocking Calls.

[louthy]

Short answer. No.

Longer answer, well, firstly you should read this post in its entirety, because the reasoning is all there.

All code, even 'synchronous' code, runs concurrently. We write our code and the operating system allocates its resource (the CPU and its threads) to use for a period of time before our threads yield so that other programs running on the OS can share that CPU resource.

If that's the case, then what actually is the difference between synchronous (where the OS intervenes) and 'async/await' code? I'd argue: not much! async/await has explicit yield points where it says "I've got some IO to do, so task-pool, you can run something else on this thread". It's cooperative and means your application can best use the resources it's been allocated by the OS.

So, if regular OS multitasking is transparent, why isn't async/await transparent and automatic? Why are we explicitly annotating (and colouring) our code for something that is a basic property of a multitasking system?

I believe Microsoft got it wrong with async/await and it's borne out of the history of Task<T>. Before async/await we'd have to manually manage Task with ContinueWith and various other awful techniques, it was explicit and ugly. This was something that needed fixing and it was fixed with async/await: new keywords that worked with Task that would build the thread yielding state-machine automatically.

If C# never had Task and it was designed from scratch to support asynchrony, then I don't believe we'd ever have async/await. Why?

1. The most common thing to do with Task is to await it.
2. The least common thing to do with Task is to fork it (run it in parallel)
   • That doesn't mean we never do it, but we await more

These two points should make it abundantly clear what should have happened when designing a concurrency system for C#

1. Regular awaiting should just look like any other code
2. fork should have been a new keyword

That would mean the absolute code explosion in *Async variants would never have been needed. It would mean all code composes in the standard way, no gymnastics to make sync and async work together. And it means that you could have some async function added into a sync function without then having to refactor the dependency tree of code that uses that function to return Task and await all the way up to Main.

This is the 'green' threads approach and that's what I have built. There is no blocking of threads, everything yields in the same way as async/await. It's just you don't have to do that manually and you don't have to change entire code-graphs to use it. When you want to do something in-parallel then you use forkIO on monads or monad stacks that support IO. This is a much more pragmatic approach to concurrency and parallelism and makes everything composable with everything else without and additional *Async variants.

It's part of the removal of over 500,000 lines of code from the v5 release, so as I am sure you understand, this isn't going to change. If you aren't happy with this answer then the v4-latest branch is the most up-to-date v4 version of language-ext. This project is MIT licensed, so you can fork that branch and maintain your own version.

[seungyongshim]

However, Is there a way to resolve the thread exhaustion issue in ASP.NET Core when using version 5?

https://github.com/seungyongshim/poc-language-ext-v4-v5

  _   _   ____                        _                       ____
 | \ | | | __ )    ___    _ __ ___   | |__     ___   _ __    | ___|
 |  \| | |  _ \   / _ \  | '_ ` _ \  | '_ \   / _ \ | '__|   |___ \
 | |\  | | |_) | | (_) | | | | | | | | |_) | |  __/ | |       ___) |
 |_| \_| |____/   \___/  |_| |_| |_| |_.__/   \___| |_|      |____/

21:58:44 [INF] NBomber "5.7.0" started a new session: "2024-08-16_12.58.28_session_4a09dd43"
21:58:44 [INF] NBomber started as single node
21:58:44 [INF] License validation....
21:58:44 [WRN] THIS VERSION IS FREE ONLY FOR PERSONAL USE. You can't use it for an organization.
21:58:44 [INF] Reports folder: "C:\2024\poc-language-ext-v4-v5\src\ConsoleApp1\bin\Debug\net8.0\reports\2024-08-16_12.58.28_session_4a09dd43"
21:58:44 [INF] Plugins: no plugins were loaded
21:58:44 [INF] Reporting sinks: no reporting sinks were loaded
21:58:44 [INF] Starting init...
21:58:44 [INF] Target scenarios: "v4"
21:58:44 [INF] Init finished
21:58:44 [INF] Starting bombing...
21:59:15 [INF] Waiting on scenarios completion...
21:59:19 [INF] Stopping scenarios...
21:59:19 [INF] Calculating final statistics...

────────────────────────────────────────────────────── test info ───────────────────────────────────────────────────────
test suite: nbomber_default_test_suite_name
test name: nbomber_default_test_name
session id: 2024-08-16_12.58.28_session_4a09dd43

──────────────────────────────────────────────────── scenario stats ────────────────────────────────────────────────────
scenario: v4
  - ok count: 15000
  - fail count: 0
  - all data: 0.7 MB
  - duration: 00:00:30

load simulations:
  - inject, rate: 500, interval: 00:00:01, during: 00:00:30

┌─────────────────────────┬───────────────────────────────────────────────────────────┐
│                    step │ ok stats                                                  │
├─────────────────────────┼───────────────────────────────────────────────────────────┤
│                    name │ global information                                        │
│           request count │ all = 15000, ok = 15000, RPS = 500                        │
│            latency (ms) │ min = 999.1, mean = 1009.76, max = 1038.79, StdDev = 4.64 │
│ latency percentile (ms) │ p50 = 1011.2, p75 = 1013.76, p95 = 1015.3, p99 = 1015.81  │
│      data transfer (KB) │ min = 0.045, mean = 0.045, max = 0.045, all = 0.7 MB      │
└─────────────────────────┴───────────────────────────────────────────────────────────┘

status codes for scenario: v4
┌─────────────┬───────┬─────────┐
│ status code │ count │ message │
├─────────────┼───────┼─────────┤
│          OK │ 15000 │         │
└─────────────┴───────┴─────────┘


21:59:19 [INF] Reports saved in folder: "C:\2024\poc-language-ext-v4-v5\src\ConsoleApp1\bin\Debug\net8.0\reports\2024-08-16_12.58.28_session_4a09dd43"
21:59:19 [WRN] THIS VERSION IS FREE ONLY FOR PERSONAL USE. You can't use it for an organization.
  _   _   ____                        _                       ____
 | \ | | | __ )    ___    _ __ ___   | |__     ___   _ __    | ___|
 |  \| | |  _ \   / _ \  | '_ ` _ \  | '_ \   / _ \ | '__|   |___ \
 | |\  | | |_) | | (_) | | | | | | | | |_) | |  __/ | |       ___) |
 |_| \_| |____/   \___/  |_| |_| |_| |_.__/   \___| |_|      |____/

21:59:19 [INF] NBomber "5.7.0" started a new session: "2024-08-16_12.59.76_session_3481fefb"
21:59:19 [INF] NBomber started as single node
21:59:19 [INF] License validation....
21:59:19 [WRN] THIS VERSION IS FREE ONLY FOR PERSONAL USE. You can't use it for an organization.
21:59:19 [INF] Reports folder: "C:\2024\poc-language-ext-v4-v5\src\ConsoleApp1\bin\Debug\net8.0\reports\2024-08-16_12.59.76_session_3481fefb"
21:59:19 [INF] Plugins: no plugins were loaded
21:59:19 [INF] Reporting sinks: no reporting sinks were loaded
21:59:19 [INF] Starting init...
21:59:19 [INF] Target scenarios: "v5"
21:59:19 [INF] Init finished
21:59:19 [INF] Starting bombing...
21:59:38 [INF] Waiting on scenarios completion...
21:59:42 [INF] Calculating final statistics...

────────────────────────────────────────────────────── test info ───────────────────────────────────────────────────────
test suite: nbomber_default_test_suite_name
test name: nbomber_default_test_name
session id: 2024-08-16_12.59.76_session_3481fefb

──────────────────────────────────────────────────── scenario stats ────────────────────────────────────────────────────
scenario: v5
  - ok count: 325
  - fail count: 6604
  - all data: 0.0 MB
  - duration: 00:00:19

load simulations:
  - inject, rate: 500, interval: 00:00:01, during: 00:00:30

┌─────────────────────────┬─────────────────────────────────────────────────────────────────┐
│                    step │ ok stats                                                        │
├─────────────────────────┼─────────────────────────────────────────────────────────────────┤
│                    name │ global information                                              │
│           request count │ all = 6929, ok = 325, RPS = 17.1                                │
│            latency (ms) │ min = 1019.6, mean = 16236.56, max = 22512.29, StdDev = 6801.21 │
│ latency percentile (ms) │ p50 = 18743.29, p75 = 20398.08, p95 = 22315.01, p99 = 22495.23  │
│      data transfer (KB) │ min = 0.045, mean = 0.045, max = 0.045, all = 0.0 MB            │
└─────────────────────────┴─────────────────────────────────────────────────────────────────┘
┌─────────────────────────┬──────────────────────────────────────────────────────────────┐
│                    step │ failures stats                                               │
├─────────────────────────┼──────────────────────────────────────────────────────────────┤
│                    name │ global information                                           │
│           request count │ all = 6929, fail = 6604, RPS = 347.6                         │
│            latency (ms) │ min = 4045.76, mean = 4102.41, max = 4207.11, StdDev = 33.93 │
│ latency percentile (ms) │ p50 = 4091.9, p75 = 4110.34, p95 = 4177.92, p99 = 4194.3     │
└─────────────────────────┴──────────────────────────────────────────────────────────────┘

status codes for scenario: v5
┌─────────────┬───────┬─────────────────────────────────────────────────────────────────────────────────────────────┐
│ status code │ count │ message                                                                                     │
├─────────────┼───────┼─────────────────────────────────────────────────────────────────────────────────────────────┤
│          OK │  325  │                                                                                             │
│        -101 │ 6604  │ No connection could be made because the target machine actively refused it. (localhost:5111)│
└─────────────┴───────┴─────────────────────────────────────────────────────────────────────────────────────────────┘


21:59:42 [INF] Reports saved in folder: "C:\2024\poc-language-ext-v4-v5\src\ConsoleApp1\bin\Debug\net8.0\reports\2024-08-16_12.59.76_session_3481fefb"
21:59:42 [WRN] THIS VERSION IS FREE ONLY FOR PERSONAL USE. You can't use it for an organization.

Best Regards

[louthy]

As mentioned earlier, forking is the key primitive rather than awaiting.

If you change effect.Run(); to effect.ForkIO().Run(); then you'll get the number you expected:

scenario: v5
  - ok count: 15000
  - fail count: 0
  - all data: 1.1 MB
  - duration: 00:00:30

You can also await the fork like so:

var operation = from f in effect.ForkIO()
                from _ in f.Await
                select unit;

operation.Run();

I notice that awaiting example is a little slow (at least I think that's the case, I haven't used NBomber before and am not entirely sure what all the numbers are yet!). But, it's not due to thread starvation, probably just inefficiency in the current implementation of Eff or its inner IO monad, or maybe even in the awaiter itself. I'll look into that.

I am yet to do any serious optimisation work on the v5-beta. Types like Eff are currently implemented as monad transformers as a proof-of-concept for monad transformers in general (dog-fooding my own code); but to make it as optimal as v4 then a handwritten monad will be more efficient - I'm just putting that off until the feature-set settles down.

[louthy]

With a little bit of tweaking, the Await version is at these numbers (with no failures):

scenario: v5
  - ok count: 2800
  - fail count: 0
  - all data: 0.2 MB
  - duration: 00:00:30

I've also added a RunAsync to make it easier to launch IO based monads in existing async/await blocks.

app.MapGet("/", async () =>
                {
                    var effect = liftIO(async () =>
                                        {
                                            await Task.Delay(1000).ConfigureAwait(false);
                                            return unit;
                                        });

                    await effect.RunAsync();
                });

All it does behind the scenes is fork the IO computation and then returns the AwaitAsync property which is a new property that results in a Task.

public Task<A> RunAsync(EnvIO? envIO = null)
{
    envIO ??= EnvIO.New();
    var f = Fork().Run(envIO);
    return f.AwaitAsync.Run(envIO);
}

This is already doing 10 times as many items as an hour ago. I don't particularly want to get knee deep into optimisations right now, but I doubt it'd be too hard to get back to the v4 performance from here.

[louthy]

don't particularly want to get knee deep into optimisations right now,

Ok, I take that ^^^ back, I now have it working at full speed with the RunAsync method.

scenario: v5
  - ok count: 15000
  - fail count: 0
  - all data: 0.7 MB
  - duration: 00:00:30

There's still plenty of optimisations I can do, but I think this shows it's not an invalid approach.