Just had a moment ...

[louthy]

I just had a moment, whilst building the new monad-transformer functionality, where the elegance of the solution - that I have been working night and day to make - finally appeared. And, I felt like sharing!

var m1 = ReaderT<string, Maybe, int>.Lift(Maybe<int>.Just(123));
var m2 = ReaderT<string, Maybe, int>.Lift(Maybe<int>.Just(123));

var m3 = from w in Pure(123)
         from x in m1
         from r in use(() => File.Open("c:\\test.txt", FileMode.Open))
         from y in m2
         from z in Maybe<int>.Just(100)
         from e in ask<string>()
         from _ in release(r)
         select $"{e}: {w + x + y + z}";

var r1 = m3.Run("Hello");

What you see here is the ReaderT monad-transformer lifting a Maybe<int> (meaning we have a composition of Reader behaviour and Maybe behaviour - so we have an environment value we can access via ask and we have optional results).

Maybe<A> is just a test type, it won't be in the final release.

Other things you see here are:

• Pure(123) - this generates a Pure<int> type, which is the new type for lifting a pure value into any monad. So we don't need things like SuccessEff, FinSucc, etc. just use Pure for everything.
• use and release - all transducer based monads can acquire resources and will manage their lifetime automatically. If you don't call release or the computation fails before getting to the release call, the resource will automatically be freed.
• ask<string>() - returns an Ask<Env, A> type that will work with any MonadReaderT derived type.
• You can see the direct use of Maybe<int>.Just(100) in the LINQ expression. Unlike Haskell where the monad has to be manually lifted into the transformer, we can just use it directly and it all just works.

And, to show this isn't just a fluke, we can use any monad we like in the ReaderT transformer (and indeed, stack many of them, like Haskell). Below is the same example with Either.

var m1 = ReaderT<string, Either<string>, int>.Lift(Right(123));
var m2 = ReaderT<string, Either<string>, int>.Lift(Right(123));

var m3 = from w in Pure(123)
         from x in m1
         from r in use(() => File.Open("c:\\test.txt", FileMode.Open))
         from y in m2
         from z in Right(100)
         from e in ask<string>()
         from _ in release(r)
         select $"{e}: {w + x + y + z}";

And, what about if we want to define a regular Reader monad (which in Haskell is a ReaderT monad with the Identity monad lifted into it)? Well, we can do that too:

public record Reader<Env, A>(Transducer<Env, Monad<MIdentity, A>> runReaderT)
    : ReaderT<Env, MIdentity, A>(runReaderT);

And that's it. Without writing any more code, I can use the Reader monad:

var m1 = Reader<string, int>.Pure(123);
var m2 = Reader<string, int>.Pure(123);
        
var m3 = from x in m1
         from y in m2
         from e in ask<string>()
         select $"{e}: {x + y}";

But of course, that Reader type is effectively working as an alias, so we can alias anything we want to make bespoke composed monads. For example, we can build domain specific monads:

// Domain monad - a composition of Reader (with a fixed AppConfig environment) and Either<Error, A>
public record App<A>(Transducer<AppConfig, Monad<Either<Error>, A>> runReader)
    : ReaderT<AppConfig, Either<Error>, A>(runReader);

// Application environment
public record AppConfig(string ConnectionString, string RootFolder);

And extend them with convenience methods:

public static class App
{
    public static App<A> Pure<A>(A value) =>
        (App<A>)App<A>.Pure(value);

    public static App<A> Fail<A>(Error error) =>
        (App<A>)App<A>.Lift(Left<Error, A>(error));

    public static App<string> connectionString =>
        (App<string>)App<string>.Asks(env => env.ConnectionString);

    public static App<string> rootFolder =>
        (App<string>)App<string>.Asks(env => env.RootFolder);    
}

NOTE: The casting is a little annoying, it isn't required as you can work with the raw ReaderT result, but makes the interface slightly more elegant. This will be one for the new source-genertors.

And once you have made your App monad, it becomes instantly usable in LINQ expressions and the like:

var m1 = App.Pure(123);
var m2 = App.Pure(123);
var m3 = App.Fail<int>(Error.New("fail"));
        
var m4 = from w in Pure(234)
         from x in m1
         from y in m2
         from z in m3
         from r in App.rootFolder
         select $"{r}: {w + x + y + z}";

var r1 = await m4.RunAsync(new AppConfig("", ""));

Another nicety is that because of the Drop all Async variants proposal (which is leading to a more 'green threads' approach), all monads - that you build using monad-transformers - will automatically have async support. Here's the above example with an async operation injected:

var m1 = App.Pure(123);
var m2 = App.Pure(123);
var m3 = App.Fail<int>(Error.New("fail"));
       
var m4 = from w in Pure(234)
         from x in m1
         from y in m2
         from z in m3
         from r in App.rootFolder
         from t in liftAsync(async () => await File.ReadAllTextAsync($"{r}\\test.txt"))
         select $"{t}: {w + x + y + z}";

var r1 = await m4.RunAsync(new AppConfig("", ""));

I still have a lot of typing to do to get everything in place. But., today was the first time I saw that the monad transformers can work in a way that isn't just a nightmare of generics, which means v5 is going to be a big leap in capability!

Party time :-)