Async Effects changes between v4 and v5

[rhemsuda]

The following code is now giving me an error message saying:

Cannot convert async lambda expression to delegate type 'Func<Option<Lst<Document>>>'. An async lambda expression may return void, Task or Task<T>, none of which are convertible to 'Func<Option<Lst<Document>>>'.

When I moved from v4 to v5-latest. Does anyone have any examples of what I should do? Also is v5 technically stable enough to use at my company? I'm currently tasked with building a foundation for a large re-write and they've allowed me to explore this library on work hours because I've made such a good case for FP. I want to make sure that I give this library a good first impression.

public class DocumentRepository : IDocumentRepository
{
    public Eff<Option<Document>> GetDocumentByIdAsync(DocumentDbContext context, Guid id) =>
        Eff<Option<Document>>.Effect(async () => {
            var document = await context.Set<Document>().FindAsync(id);
            return (document == null) 
                ? Option<Document>.None 
                : Option<Document>.Some(document);
        });


    public Eff<Option<Lst<Document>>> GetAllDocumentsAsync(DocumentDbContext context) =>
        Eff<Option<Lst<Document>>>.Effect(async () => {
            var documents = await context.Set<Document>().ToListAsync();
            return documents.Count > 0 
                ? Option<Lst<Document>>.Some(new Lst<Document>(documents))
                : Option<Lst<Document>>.None;
        });
}

[rhemsuda]

I just noticed that ".Effect" is deprecated. I replaced with LiftIO and the error has gone away, but I'm not sure if this is the correct way to implement this. The documentation of Effect just does Eff(async () => { }); which I'm also not sure if this should be able to handle the type inference or not, given it is C#

[louthy]

Everything that can do async now must have an IO<A> within. Eff<A> is effectively a wrapper for Eff<Unit, A>. Which is a wrapper for ReaderT<Unit, IO, A> -- so it has an IO<A>within.

Every type that does IO usually has some bespoke functionality for lifting IO<A> or a Task.

liftEff

Eff<A> has liftEff, which only works with the Eff monads:

public Eff<Option<Document>> GetDocumentByIdAsync(DocumentDbContext context, Guid id) =>
    liftEff(async () => Optional(await context.Set<Document>().FindAsync(id))));

liftIO

But for types that don't have a bespoke function like liftEff, they may well have an implicit cast from IO<A> to M<A> (Eff<A> in this case). Eff<A> supports implicit casts from IO<A>:

public Eff<Option<Document>> GetDocumentByIdAsync(DocumentDbContext context, Guid id) =>
    liftIO(async () => Optional(await context.Set<Document>().FindAsync(id))));

MonadIO.liftIO

For types that have LiftIO implemented in their traits, but don't have bespoke functionality for lifting tasks, you can use the trait implementation to lift the async function:

public Eff<Option<Document>> GetDocumentByIdAsync(DocumentDbContext context, Guid id) =>
    MonadIO.liftIO<Eff, Option<Document>>(
        liftIO(async () => Optional(await context.Set<Document>().FindAsync(id)))).As();

You can see how it bakes in the Eff trait-implementation type into the general-purpose MonadIO.liftIO function. We can do this for any type that has a MonadIO trait implementation.

Or, why not completely generalise!

You can also now generalise your code and remove the dependency on using Eff<A> entirely:

public K<M, Option<Document>> GetDocumentByIdAsync<M>(DocumentDbContext context, Guid id) 
    where M : Monad<M> =>
    MonadIO.liftIO<M, Option<Document>>(
        liftIO(async () => Optional(await context.Set<Document>().FindAsync(id))));

There's no mention of Eff anywhere, we now allow monads of any flavour.

Then you can parameterise it with the monad you're using:

Eff<Option<Document>> effect = GetDocumentByIdAsync<Eff>(context, id).As();

Why is that useful? Well, if you build any bespoke monad-transformer stacks (with IO<A> as the base-monad) you can just use GetDocumentByIdAsync with any of them.

For example, the Game monad in the CardGame sample is simply a wrapper around this monad-transformer stack:

StateT<GameState, OptionT<IO>, A>

So it has IO<A> as the base-monad.

And just like the example above, we can parameterise the method:

Game<Option<Document>> effect = GetDocumentByIdAsync<Game>(context, id).As();

This is one of the superpowers of the new trait based approach. It allows us to build domain-specific monads (like a Db<A> monad, for example). Just like you would in a Haskell application.

lift

In general the library now uses Lift* and lift* to get computations lifted into the monadic types. So, if you struggle in future, just look for the lift methods and functions.

[rhemsuda]

OR, maybe I could even write a Roslyn analyzer to detect if a switch statement has exhausted all implementations of an interface. That might be better if I can get it to work.

[louthy]

There's another approach to using records which:

• Stops others from inheriting from the 'sum type' (stopping new cases being added elsewhere in the codebase)
• Stops the case-types being used as a base-type for other types

If you make the base 'sum type' have a private constructor, nobody else can inherit from it. Then move the case-types into the sum-type's definition. And, finally, make the case-types sealed:

public abstract record Status
{
    private Status(){}
    public sealed record InvalidFormat(Guid Id) : Status;
    public sealed record Exists(Guid Id) : Status;
    public sealed record DatabaseError(Guid Id, Error Error) : Status;
}

You can then add a Match function:

public abstract record Status
{
    private Status(){}
    public sealed record InvalidFormat(Guid Id) : Status;
    public sealed record Exists(Guid Id) : Status;
    public sealed record DatabaseError(Guid Id, Error Error) : Status;

    public A Match<A>(
        Func<Guid, A> InvalidFormat,
        Func<Guid, A> Exists,
        Func<Guid, Error, A> DatabaseError) =>
        this switch
        {
            InvalidFormat (var id)        => InvalidFormat(id),
            Exists (var id)               => Exists(id),
            DatabaseError (var id, var e) => DatabaseError(id, e),
            _                             => throw new InvalidOperationException()
        };
}

It's a bit more effort, but it does force consideration of all cases.

You can used named parameters to make it look like constructor matching:

var result = status.Match(
    InvalidFormat: id        => 1,
    Exists: id               => 2,
    DatabaseError: (id, err) => 3);

The downside to this is you can't put additional constraints on cases like you can with regular pattern matching. And you can't do nested matching, which is obviously useful.

I've given up worrying about exhaustivity-check failure and just take more care when I use C#'s pattern-matching. Primarily because I often want to do nested matching and have additional when constraints. C#'s pattern-matching is actually decent, so I'd rather have that expressiveness.

[rhemsuda]

@louthy really appreciate your help. I'm starting to see the light with this library however the explicit nature of generics has been giving me some troubles and I'm wondering if there's some underlying concept that I'm misunderstanding as to how you've implemented the type inference:

I'm still finding myself writing stuff like this:

    public Eff<Either<AddDocumentError, Document>> AddDocumentAsync(
        DocumentDbContext context,
        Validation<DocumentValidationError, Document> document
    ) => 
        liftIO(async () => {
            return await document.Match(
                Succ: async doc => {
                    var existingDocument = await context.Set<Document>().FindAsync(doc.ID);
                    if (existingDocument != null) 
                    {
                        return Left<AddDocumentError, Document>(new AddDocumentError.Exists(existingDocument));
                    }
                    return Right<AddDocumentError, Document>(doc);
                },
                Fail: err => Task.FromResult(Left<AddDocumentError, Document>(new AddDocumentError.ValidationFailure(err)))
            );   

I've also made your suggested changes for the union types to try it out, and in order for validation to work I've implemented Monoid on my validation error:

public abstract record AddDocumentError
{
  private AddDocumentError(){}
  public sealed record ValidationFailure(DocumentValidationError Error) : AddDocumentError;
  public sealed record Exists(Document ExistingDocument) : AddDocumentError;
  public sealed record DatabaseError(Guid Id, Error Error) : AddDocumentError;
}


public class DocumentValidationError : Monoid<DocumentValidationError>
{
  public string ErrorMessage { get; }
  
  public DocumentValidationError(string errorMessage)
  {
      ErrorMessage = errorMessage;
  }

  static DocumentValidationError Monoid<DocumentValidationError>.Empty 
      => new DocumentValidationError(string.Empty);

  public DocumentValidationError Combine(DocumentValidationError rhs) 
      => new DocumentValidationError($"{ErrorMessage}; {rhs.ErrorMessage}");
}

Which is a little messy for my liking. A few things I'd like to clarify if you don't mind.

1. Am I thinking about the Validation argument the right way? I saw an example of someone using your library and they did this because they essentially wanted to bind the validation to this function, so that if we have a chain of validators, we can just pass in the validation result to this function. In Haskell we would use a Monad which is why this feels a little weird to me, and I'm assuming there;s a better way to handle this with your library.
2. Do Left and Right need to re-define the types here? When I remove them I get an error stating Anonymous function converted to a void returning delegate cannot return a value.
3. Why do I need to use Task.FromResult for the failure? Without this hack, I get an error where it says Argument 1: cannot convert from 'LanguageExt.Common.Error' to 'DocumentValidationError'. I get a weird feeling that neither this or the error in option 2. are the actual root causes, because when I do either of these changes, both errors pop up, and frankly they don't really make sense to me. It seems that the type inference capabilities are getting confused in either case.

Any information you can provide about how this is actually being handled would be helpful to me. It's been a while since I've used C# and so I'm guessing that there are some language features that are messing me up.

Cheers,
Kyle

[louthy]

It seems to me to be a mistake to take a Validation as an argument. You should only call AddDocumentAsync with a valid Document, not one that might be invalid and cause the function to early-out and do nothing. The acquisition of the document should happen outside of the function imho.

That would simplify your code somewhat:

public Eff<Either<AddDocumentError, Document>> AddDocumentAsync(
    DocumentDbContext context,
    Document document) =>
    from d in liftEff(() => context.Set<Document>().FindAsync(document.ID))
    select d is null
               ? Right(document)
               : Left<AddDocumentError, Document>(new AddDocumentError.Exists(d));

In terms of inference, C# infers mostly from arguments, not assignments. So, if you have a function:

Either<L, R> Right<L, R>(R value);

Then only the R can be inferred. And so, C# will want you to specify all of the type-parameters. Which is annoying, obviously.

If you look in the Prelude there are two overloads for Right:

public static Either<L, R> Right<L, R>(R value) =>
    new Either.Right<L, R>(value);

public static Pure<R> Right<R>(R value) =>
    new (value);

The second one only takes one type-parameter (which can be inferred), but it doesn't construct an Either<L, R>, it constructs a Pure<R>. And so, we can write Right(123) to get a Pure<int>.

The Either<L, R> type has an implicit operator that will implicitly cast from a Pure<R> to an Either<L, R>:

public static implicit operator Either<L, R>(Pure<R> mr) =>
    Right(mr.Value);

So, once the type is known to be an Either with two known L, R parameters, then an implicit cast can happen from the Pure<R> to the Either<L, R>, so this works:

static Either<string, int> Test(bool flag) =>
    flag
        ? Right(100)
        : Left("fail");

NOTE: Even with this technique, sometimes C# can't resolve. I wish the language had better type-inference, but I guess it's also the reason the compiler is so fast, so swings and roundabouts...

The problems you had in your example with inference is that:

new AddDocumentError.Exists(existingDocument);
new AddDocumentError.ValidationFailure(err);

Returns the case-types, not the base type. That means the Succ and Fail branches are resulting in fundamentally different types and so the version of Match, that expects a common type for Succ and Fail, fails to resolve. What C# then assumes (which I find annoying) is that you must have wanted the Action version of Match all along (even though you are explicitly returning values).

public Unit Match(Action<A> Succ, Action<F> Fail) =>

So, that's why that error is weird. It's because C# refuses to accept that we might have wanted the Func version of Match and we just got our types mixed up!

When I build DUs I tend to create static constructor functions that return the base-type:

public abstract record Maybe<A>;
public record Just<A>(A Value) : Maybe<A>;
public record None<A>() : Maybe<A>;

public static class Maybe
{
    public static Maybe<A> Just<A>(A value) => new Just<A>(value);
    public static Maybe<A> Nothing<A>() => new Nothing<A>();
}

This works well for parametric DUs, but is a bit awkward for concrete DUs because the constructor functions and type-names are the same:

public abstract record AddDocumentError
{
    private AddDocumentError(){}

    public static AddDocumentError ValidationFailure(DocumentValidationError error) => new ValidationFailureCase(error);
    public static AddDocumentError Exists(Document existingDocument) => new ExistsCase(existingDocument);
    public static AddDocumentError DatabaseError(Guid id, Error error) => new DatabaseErrorCase(id, error);
    
    public sealed record ValidationFailureCase(DocumentValidationError Error) : AddDocumentError;
    public sealed record ExistsCase(Document ExistingDocument) : AddDocumentError;
    public sealed record DatabaseErrorCase(Guid Id, Error Error) : AddDocumentError;
}

But, the upside is you can drop the new and treat them as genuine constructor functions:

public Eff<Either<AddDocumentError, Document>> AddDocumentAsync(
    DocumentDbContext context,
    Document document) =>
    from d in liftEff(() => context.Set<Document>().FindAsync(document.ID))
    select d is null
               ? Right(document)
               : Left<AddDocumentError, Document>(AddDocumentError.Exists(d));

Anyway, you could have used the Left and Right functions that infer as long as you were working with the base-type and not case-types and as long as there's a known Either type to implicitly cast to.

From your original code, this would work:

var existingDocument = await context.Set<Document>().FindAsync(doc.ID);
if (existingDocument != null)
{
    return Left(new AddDocumentError.Exists(existingDocument) as AddDocumentError); // casting to the base
}

return Right<AddDocumentError, Document>(doc);

Btw, I'd encourage usage of ternaries and switch expressions rather than that style of if:

await context.Set<Document>().FindAsync(doc.ID) switch
{
    null => Right<AddDocumentError, Document>(doc),
    var d => Left(AddDocumentError.Exists(d))
}

[rhemsuda]

Thank you so much for your help. I really appreciate it. I will close this conversation and open up a new discussion if I have further questions :)