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.

[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).