Improving Composability in my codebase

[rhemsuda]

Hey everyone,

I'm still relatively new to functional programming so please go easy on me if this is a stupid question, but I'm struggling a bit to make some code that I have composable and I'm often finding myself writing redundant bits of code where I often have to Match pre-maturely rather than binding all my functions together and dealing with errors at the boundary of my application.

Take this code for instance:

public static Eff<Either<Error, JobExecutionData>> GetExecutionAsync(BatchJobDbContext context, BatchJobName name, DateOnly executionDate) => 
        liftEff(async () => 
            Optional(await context.JobExecutions.FindAsync(name.Value, executionDate))
                .ToEither(Error.New($"Cannot find execution named {name.Value} on date {executionDate}"))
            )
            .Bind(eitherEntity => eitherEntity.Match(
                Left: err => err,
                Right: entity => GetAllStatusChangesAsync(context, entity.Name, entity.ExecutionDate).Map(statusChanges => 
                    JobExecutionEntity.ToDomain(entity, statusChanges)
                )
            ));

public static Eff<Seq<JobStatusChange>> GetAllStatusChangesAsync(BatchJobDbContext context, string jobName, DateOnly dateKey) 
        => liftEff(async ()
            => Optional(await context.JobStatusChanges.Where(s => s.JobName == jobName && s.Time.DateOnly() == dateKey).ToListAsync())
            .Map(list => list.ToSeq())
            .Bind(entities => entities.Map(entity =>
                JobStatusChangeEntity.ToDomain(entity).ToOption()
            ).Somes())            
        ).Map(lst => lst.ToSeq());


public record JobStatusChangeEntity
{
    public required string JobName { get; init; }
    public required DateTime Time { get; init; }
    public string? FromStatus { get; init; }
    public required string ToStatus { get; init; }

    public static Either<Error, JobStatusChangeEntity> FromDomain(JobStatusChange domain) =>
        Right(new JobStatusChangeEntity {
            JobName = domain.JobName.Value,
            Time = domain.Time,
            FromStatus = domain.From.Match(
                Some: from => from.ToString(),
                None: () => null!
            ),
            ToStatus = domain.To.ToString()
        });

    public static Either<Error, JobStatusChange> ToDomain(JobStatusChangeEntity entity) =>
        from jobName in BatchJobName.Create(entity.JobName)
        let fromStatus = JobStatus.Parser().Parse(entity.FromStatus ?? string.Empty).ToOption()
        from toStatus in JobStatus.Parser().Parse(entity.ToStatus).ToEither(Error.New)        
        from jobStatusChange in JobStatusChange.Create(
            jobName,
            entity.Time,
            fromStatus,
            toStatus
        )
        select jobStatusChange;        
}

public record JobExecutionEntity
{
    public required string Name { get; init; }
    public required DateOnly ExecutionDate { get; init; }
    public required TimeOnly ExecutionTime { get; init; }

    public static Either<Error, JobExecutionEntity> FromDomain(JobExecutionData domain) =>
        new JobExecutionEntity {
            Name = domain.JobName.Value,
            ExecutionDate = domain.ExecutionTime.DateOnly(),
            ExecutionTime = domain.ExecutionTime.TimeOnly()
        };
    
    public static Either<Error, JobExecutionData> ToDomain(JobExecutionEntity entity, Seq<JobStatusChange> jobStatusChanges) =>
        JobExecutionData.Create(entity.Name, new DateTime(entity.ExecutionDate, entity.ExecutionTime), jobStatusChanges);

I'm dealing with EntityFramework at this point in my codebase, and want to bind my effect operations together and deal with them at my controller level so that all side-effects occur at the boundary of my application.

As you can see in the GetExecutionAsync function (and probably elsewhere lol), there is some redundant code, particularly this bit:

eitherEntity.Match(
    Left: err => err,
    Right: entity => GetAllStatusChangesAsync(context, entity.Name, 
    ...

To my understanding, instead of using .Match, I should be able to use .Bind to pass on the responsibility of matching to the caller of this function. The return type is Eff<Either<Error, JobExecutionEntity>> which I've called Bind on to operate on the Either<Error, JobExecutionEntity>, but then when I call Bind again (instead of Match) to get the JobExecutionEntity, I get compiler errors when passing the JobExecutionEntity into GetAllStatusChangesAsync:

public static Eff<Either<Error, JobExecutionData>> GetExecutionAsync2(BatchJobDbContext context, BatchJobName name, DateOnly executionDate)
        => liftEff(async () => 
            Optional(await context.JobExecutions.FindAsync(name.Value, executionDate))
                .ToEither(Error.New($"Cannot find execution named {name.Value} on date {executionDate}"))
            )
            .Bind(eitherEntity => eitherEntity.Bind(entity => 
                GetAllStatusChangesAsync(context, entity.Name, entity.ExecutionDate).Map(statusChanges => 
                    JobExecutionEntity.ToDomain(entity, statusChanges)
                )
            ));

'Unit' does not contain a definition for 'Name' and no accessible extension method 'Name' accepting a first argument of type 'Unit' could be found (are you missing a using directive or an assembly reference?)

Based on the code that I've seen in Samples, my code looks a lot more sloppy, however in many cases I haven't been able to get from .. in .. syntax working. There are some examples in my code that I'm happy with, but this is an area of my code that has really been bothering me. I've been able to do similar stuff to this in Haskell and the type-inference system has done a lot of the heavy-lifting for me, but doing this in CSharp has been a thorn in my side for quite a while.

Does anyone have any ideas what I might be doing wrong? I'm very much open to criticism here and ultimately want to get better at this. I'm happy to provide more context if needed.

Thanks in advance.

Kyle

[matteomalinverni]

Hi Kyle, I'm also relatively new to this library and still wrapping my head around some of the deeper patterns, but from what I’ve understood so far I think I can help clarify what’s going on here.

In your second example:

.Bind(either => either.Bind(...))

The outer .Bind is working on Eff, so your lambda needs to return an Eff.
But you're calling .Bind on the inner Either, which returns an Either, not an Eff — and that’s where the compiler gets confused.

You can match on the Either inside the Eff context and promote the result with Fail() or continue with another Eff:

.Bind(either =>
    either.Match(
        Left: err => Fail<JobExecutionData>(err),
        Right: entity =>
            GetAllStatusChangesAsync(...).Map(statusChanges =>
                JobExecutionEntity.ToDomain(entity, statusChanges)
            )
    )
)

This way, everything stays inside Eff and you're handling both paths cleanly.
Hope this helps — I’ve run into the same thing myself.
Matteo

[aloslider]

1. Eff<Either<Error, JobExecutionData>> is redundant, Eff<T> is already using Fin<T> which is basically an Either<Error, T>.
2. Based on the code I see there are a plenty of monad transofmations (usually Option, Either and Eff). If you are using v4, there are some built in functions to transform, say, Option to Eff. If you are using v5, there are monad transformers that you can use, which simplifies working with different stacks even more and giving you a way to build you own domain monad.
3. If you step a little bit and try to look at your example again, you may see some overcomplexification:

liftEff(async () => 
            Optional(await context.JobExecutions.FindAsync(name.Value, executionDate))
                .ToEither(Error.New($"Cannot find execution named {name.Value} on date {executionDate}"))
            )
            .Bind(eitherEntity => eitherEntity.Bind(entity => 
                GetAllStatusChangesAsync(context, entity.Name, entity.ExecutionDate).Map(statusChanges => 
                    JobExecutionEntity.ToDomain(entity, statusChanges)
                )

Here you wrap a FindAsync call to Option<T>, then convert it to Either<T> and then wrap it to Eff<Either<Error, T>>. And if entity was found you continue with unwrapping Eff<Either<Error, T>> to get nested Either<Error, T>
Let's think again:

1. Why do you wrap in Option? Because it may be null (I guess so, but I would expect it to be named FindOrDefaultAsync), fair enough
2. Why do you convert it to Either? Because you probably want to specify some extra info for the case when item was not found. But isn't it really no possible to do without stacking these monads together? Moving on...
3. Why do you bind inside another bind? Because you have a nested monads stack, sometimes it can really be that's noisy. But in your case, you could've deal with it with just an Eff<T>.
   I imagine it could be done something like that (the code is not 100% compilable as I've had to guess some parts):

static Eff<JobExecutionData> GetExecutionAsync(BatchJobDbContext context, BatchJobName name, DateOnly executionDate) =>
    // Lift IO call
    from jobExecutionEntity in liftEff(async () => await context.JobExecutions.FindAsync(name.Value, executionDate))
    // Check that entity is not null; otherwise shortcurcuit with an error
    from _                  in guard(jobExecutionEntity is null, Error.New($"Cannot find execution named {name.Value} on date {executionDate}"))
    from statusChanges      in GetAllStatusChangesAsync(context, jobExecutionEntity.Name, jobExecutionEntity.ExecutionDate)
    // Create a domain with helper function that returns Fin<JobExecutionData>
    from domain             in JobExecutionEntity.ToDomain(jobExecutionEntity, statusChanges).ToEff()
    select domain;

static Eff<Seq<JobStatusChange>> GetAllStatusChangesAsync(BatchJobDbContext context, string jobName, DateOnly dateKey) =>
    from changes in liftEff(async () => 
        await context.JobStatusChanges
            .Where(s => s.JobName == jobName && s.Time.DateOnly() == dateKey)
            .ToListAsync())
    // Create Iterable<T> from List<T> to get its capabilities, then traverse and apply `JobStatusChangeEntity.ToDomain`
    // function to each element resulting in an Iterable<T> with only elements that successfully was transformed to domain model.
    // As() and ToEff() are just helper functions to get outer monad Fin<Iterable<T>> and convert it to Eff<T> so
    // it has same type in the entire linq expression.
    from domains in changes.AsIterable().Traverse(JobStatusChangeEntity.ToDomain).As().ToEff()
    select domains.ToSeq();
    
static Eff<Unit> UsageExample(BatchJobDbContext context) =>
    from executionData in GetExecutionAsync(new BatchJobName("Test"), DateTime.Now.DateOnly())
                          | @catch(err => Log.LogInfo(err.Message)) // just an abstract example of logging error when it was not found
    select unit;

There may be more changes to improve code readability, such as bringing a runtime for Eff<RT,T> to "read" external dependencies (DbContext for example) instead of passing it in as argument, or creating your own domain model transformer to work with EF that would fit in your other monad stacks, but I don't have much context and time.

I feel I've suggested it to you already some time ago, but louthy has a good series of articles for diving in FP with language-ext v5: https://paullouth.com/

[micmarsh]

Slightly unrelated, but of possible interest to most people here; although Either types dominate introductory discussions of functional error handling, many experienced Haskellers apparently ("apparently" because I'm certainly not in that category!) seem to shy away from them, or at least not assume them by default

https://www.parsonsmatt.org/2018/11/03/trouble_with_typed_errors.html
https://tech.fpcomplete.com/blog/2016/11/exceptions-best-practices-haskell/

It's reassuring to know that LanguageExt's usage of Error in various monads is not necessarily some kind of "un-functional", but rather an ergonomic concession to the type system that's necessary in many languages, including Haskell itself.

Scala's ZIO and TypeScript's Effect actually utilize their respective language's union types in a very neat way to solve some of these problems with typed errors, and the word on the street is C# is getting some kind of union type, so it will be interesting to see if those types are as "open" as Scala and TS and if the lang-ext library or ecosystem could do something similar with them.

Sorry if this is derailing the overall discussion too much!

[louthy]

It's best to think of Either (co-product) as the dual of 2-tuple (product). In that sense it plays a fundamental role in type-theory and category-theory.

It also highlights that L doesn't mean error. Just like fst doesn't mean error in tuple. But it can be used for that reason.