Aff<RT, T> or Aff<T> with different Error Type

[timmi-on-rails]

I have an ASP.NET Core application which uses ActionResults as controller return types.
I want to compose (bind, map) Affs inside controller actions.
When one Aff fails the composition will short-circuit to a failed result.
The failure type of Eff/Aff is Error, which is the problem.
I want to thread the error type ActionResult or something different through the execution.

What would be the shortest way to implement an Aff with different error type?
I don't want to create too much boiler-plate nor do I want to loose too much utility on existing implementations.

I thought about:

1. Rewriting Aff with different Error type -> tedious, error-prone (my limited skills) and loosing existing utility
2. Using EitherAsync and creating extensions methods on Aff<>. I think in this case my extensions methods would have to call Aff.Run alot. Also, I am not sure how to deal with it, when I have a runtime RT.

Can anyone think of a neat trick/composition to reach this goal?

I can try to write down examples, if this is too unclear.

[louthy]

I don't want to create too much boiler-plate nor do I want to loose too much utility on existing implementations.

The easiest way is to derive a type from Expected or Exceptional (which both derive from Error) and then use that as your error type. That requires no changes and can be done with the existing Eff and Aff types.

Otherwise - if you desperately need to constrain the type of error - there are no shortcuts unfortunately. It's quite some effort to implement these types (to make them useful). Believe me, I wish it was easier!

The closest type would be:

Reader<RT, Either<E, A>>

But even with that definition the support functions are not there, so you'd need to write them by hand.

This is exactly what the transducers-prototype and my new virtual-machine prototype (not yet public) is all about. The effort to create these types is so extreme and is getting more extreme as I add more types (because they all interact with each other, which creates an exponential typing problem!) -- so I'm trying to create the tech that makes it easy for myself and others to create bespoke monadic-transformer stacks (which is ultimately what these composite monads are).

The idea with the transducers-prototype is to standardise the internals of all of these monadic-types so that I can develop a code-generator to create the specialisations. If you look at some of the examples you can see types like Either, Eff, and Aff being defined in terms of EitherT.

public record Either<L, R>(EitherT<Identity<Unit>, Unit, L, R> Transformer)
{
}

public record Eff<Env, A>(EitherT<IO<Env>, Env, Error, A> Transformer)
{
}

public record Aff<Env, A>(EitherT<Async<Env>, Env, Error, A> Transformer) 
{
}

EitherT is a monad-transformer that is defined in terms of a transducer:

public record EitherT<M, Env, L, R>(Transducer<Env, SumTransducer<Unit, L, Unit, R>> MorphismValue) : 
    KArr<M, Env, SumTransducer<Unit, L, Unit, R>>
    where M : Monad<M, Env>
{
   ...
}

This ^^^ is exactly the shape you're looking for. The L is your bespoke error type, the Env is the runtime and R is the bound-value. So, creating your Eff and Aff types you'd just do this:

public record Eff<Env, E, A>(EitherT<IO<Env>, Env, E, A> Transformer)
{
}

public record Aff<Env, E, A>(EitherT<Async<Env>, Env, E, A> Transformer) 
{
}

The idea being that the code-gen would understand this and build the rest of the support functions.

The virtual-machine that I mentioned is a type-system that supports higher-kinds, dependent-types, and lots of other nice features. Tools like the new source-generators will leverage the virtual-machine's type-system to do deeper introspection and transformation of the C# types so that more complex code-gen can take place (as well as support for other functionality like serialisation).

It's all part of a bigger project to put type-composition tools in the hands of the users of this library. Unfortunately, it's not trivial work, so it's going to take me some time to make it. But, when it's ready it will transform FP in C#.

One thing to note, if you're thinking of taking on the project of building Aff<RT, E, A> and Eff<RT, E, A> yourself, please don't commit it to the repo. It will likely just be replaced by my new tooling when it's ready.

[timmi-on-rails]

Thank you for your detailed response.
I will go with subtyping the Error class.
I am very excited to hear about your transducers project.