Idea/Proposal: Interfaces for Reducing (Some) "Domain Monad" Boilerplate

[micmarsh]

Disclaimer I've not used v5 or the custom domain monad pattern in production at all, so this may not be as useful as I'm imagining.

Playing around with V5 locally, I've noticed that thing domain monad wrappers often result in a lot of repeated "wrapping" and "unwrapping" boilerplate when implementing trait methods, independent of the underlying types. Upon observing this and playing around locally, I've come up with some interfaces that seem to be quite useful in initial testing

public interface DomainWrapper<Self, Inner>
{
    public static abstract K<Self, A> Wrap<A>(K<Inner, A> value);
    public static abstract K<Inner, A> Unwrap<A>(K<Self, A> ma);
}

public interface DerivingFunctor<Self, Inner> : Functor<Self>, DomainWrapper<Self, Inner>
    where Inner : Functor<Inner>
    where Self : DerivingFunctor<Self, Inner>
{
    static K<Self, B> Functor<Self>.Map<A, B>(Func<A, B> f, K<Self, A> ma)
        => Self.Wrap(Self.Unwrap(ma).Map(f));
}

public interface DerivingApplicative<Self, Inner> : Applicative<Self>, DerivingFunctor<Self, Inner>
    where Inner : Applicative<Inner>
    where Self : DerivingApplicative<Self, Inner>
{
    static K<Self, A> Applicative<Self>.Pure<A>(A value)
        => Self.Wrap(Inner.Pure(value));

    static  K<Self, B> Applicative<Self>.Apply<A, B>(K<Self, Func<A, B>> mf, K<Self, A> ma)
        => Self.Wrap(Self.Unwrap(mf).Apply(Self.Unwrap(ma)));
}

public interface DerivingMonad<Self, Inner> : Monad<Self>, DerivingApplicative<Self, Inner>
    where Inner : Monad<Inner>
    where Self : DerivingMonad<Self, Inner>
{
    static K<Self, B> Monad<Self>.Bind<A, B>(K<Self, A> ma, Func<A, K<Self, B>> f)
        => Self.Wrap(Self.Unwrap(ma).Bind(a => Self.Unwrap(f(a))));
    
    // ... same idea for MonadIO methods, omitted for brevity
}

It's pretty trivial to write these for Readable, Stateful, Fallable, Foldable etc. as well.

I stole the term "Deriving" from Haskell's deriving syntax, which I also have little to no production experience with, so there may be a more accurate and/or appropriate term to use.

As a usage example

public record MyCustomError();

public record MyCustomApp<A>(EitherT<MyCustomError, IO, A> Inner) : K<MyCustomApp, A>;

public class MyCustomApp : 
    DerivingMonad<MyCustomApp, EitherT<MyCustomError, IO>>,
    DerivingFallible<MyCustomApp, EitherT<MyCustomError, IO>, MyCustomError>
{
    public static K<MyCustomApp, A> Wrap<A>(K<EitherT<MyCustomError, IO>, A> value)
        => new MyCustomApp<A>(value.As());
    public static K<EitherT<MyCustomError, IO>, A> Unwrap<A>(K<MyCustomApp, A> ma)
        => ((MyCustomApp<A>)ma).Inner;
}

Once Wrap and Unwrap are implemented, you can attach as many Deriving behaviors as your inner type will support. I've also been experimenting locally with providing "building block" types such as FallibleReaderT and FalliableRWST that can help domain monads to more easily derive multiple behaviors. For example, given

public record FallibleRWST<R, W, S, E, M, A>(RWST<R, W, S, M, A> Value) : K<FallibleRWST<R, W, S, E, M>, A>
    where M : Monad<M>, Fallible<E, M>, Choice<M>
    where W : Monoid<W>;

public class FallibleRWST<R, W, S, E, M> 
    : DerivingMonadT<FallibleRWST<R, W, S, E, M>, RWST<R, W, S, M>, M>,
      DerivingReader<FallibleRWST<R, W, S, E, M>, RWST<R, W, S, M>, R>, 
      DerivingWriter<FallibleRWST<R, W, S, E, M>, RWST<R, W, S, M>, W>,
      DerivingState<FallibleRWST<R, W, S, E, M>, RWST<R, W, S, M>, S>,
      DerivingChoice<FallibleRWST<R, W, S, E, M>>,
      Fallible<E, FallibleRWST<R, W, S, E, M>>
    where M : Monad<M>, Choice<M>, Fallible<E, M> where W : Monoid<W>
    {
        public static K<FallibleRWST<R, W, S, E, M>, A> Wrap<A>(K<RWST<R, W, S, M>, A> value) => 
            new FallibleRWST<R, W, S, E, M, A>(value.As());
        public static K<RWST<R, W, S, M>, A> Unwrap<A>(K<FallibleRWST<R, W, S, E, M>, A> ma) =>
            ((FallibleRWST<R, W, S, E, M, A>)ma).Value;

        public static K<FallibleRWST<R, W, S, E, M>, A> Fail<A>(E error) => new FallibleRWST<R, W, S, E, M, A>(
            new RWST<R, W, S, M, A>(_ => M.Fail<(A, W, S)>(error))
        );

        public static K<FallibleRWST<R, W, S, E, M>, A> Catch<A>(
            K<FallibleRWST<R, W, S, E, M>, A> fa,
            Func<E, bool> Predicate,
            Func<E, K<FallibleRWST<R, W, S, E, M>, A>> Fail) => 
              // Implementation omitted for brevity's sake, but it involves a lot of `Wrap`, `Unwrap` and `Run`
    } 

as a pre-existing utility type, our custom domain type above can get a lot more functionality, if needed

// removing custom error type and EitherT to get slightly more readability

public record MyCustomConfig();

public record MyCustomLog();

public record MyCustomApp<A>(FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff, A> Inner) : K<MyCustomApp, A>;

public class MyCustomApp : 
    DerivingMonad<MyCustomApp, FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>>,
    DerivingFallible<MyCustomApp, FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>, Error>,
    DerivingWriter<MyCustomApp, FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>, Seq<MyCustomLog>>,
    DerivingReader<MyCustomApp, FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>, MyCustomConfig>
{
    public static K<MyCustomApp, A> Wrap<A>(
        K<FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>, A> value)
        => new MyCustomApp<A>(
            // this could obviously be cleaned up with an `As` extension 
            (FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff, A>) value
            );

    static K<FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>, A> 
        DomainWrapper<MyCustomApp, FallibleRWST<MyCustomConfig, Seq<MyCustomLog>, Unit, Error, Eff>>.Unwrap<A>(K<MyCustomApp, A> ma)
        => ((MyCustomApp<A>)ma).Inner;
}

Having these "Deriving" interfaces also opens up some interesting possibilities not strictly related to domain monads. For example, "convenience" versions of types like Validation that default to Seq rather than allowing any monoid, akin to what we find in V4 (This is something my team at work would likely want if we ever switched to V5)

public record ValidationV4<E, A>(Validation<Seq<E>, A> Inner) : K<ValidationV4<E>, A>
{
    public ValidationV4<F, A> MapFail<F>(Func<E, F> f) => new(Inner.MapFail(seq => seq.Map(f)));

    public B Match<B>(Func<A, B> Success, Func<Seq<E>, B> Fail) => Inner.Match(Success, Fail);
}

public class ValidationV4<E>
    : DerivingApplicative<ValidationV4<E>, Validation<Seq<E>>>,
      DerivingAlternative<ValidationV4<E>, Validation<Seq<E>>>,
      DerivingTraversable<ValidationV4<E>, Validation<Seq<E>>>,
      DerivingFallible<ValidationV4<E>, Validation<Seq<E>>, Seq<E>>
     // this is also now a BiFunctor, which could also be helpful once that's ironed out
{
    public static K<ValidationV4<E>, A> Wrap<A>(K<Validation<Seq<E>>, A> value) => new ValidationV4<E, A>(value.As());

    public static K<Validation<Seq<E>>, A> Unwrap<A>(K<ValidationV4<E>, A> ma) =>
        ((ValidationV4<E, A>)ma).Inner;
}

and even things like easily defining new types to capture constraints such as "non-empty"

public record NonEmptySeq<A>(A Head, Seq<A> Tail) 
    : K<NonEmptySeq, A>
    , Semigroup<NonEmptySeq<A>>
    , IEnumerable<A>
    , IAdditionOperators<NonEmptySeq<A>, Seq<A>, NonEmptySeq<A>>
    , IAdditionOperators<NonEmptySeq<A>, NonEmptySeq<A>, NonEmptySeq<A>>
{
    public IEnumerator<A> GetEnumerator() => Head.Cons(Tail).GetEnumerator();

    IEnumerator IEnumerable.GetEnumerator() => GetEnumerator();

    public NonEmptySeq<A> Combine(NonEmptySeq<A> rhs) => (NonEmptySeq<A>) this.Kind().Combine(rhs.Kind());

    public static NonEmptySeq<A> operator +(NonEmptySeq<A> left, Seq<A> right) => new(left.Head, left.Tail.Combine(right));

    public static NonEmptySeq<A> operator +(NonEmptySeq<A> left, NonEmptySeq<A> right) => left.Combine(right);
}

public class NonEmptySeq 
    : DerivingMonad<NonEmptySeq, Seq>,
      DerivingTraversable<NonEmptySeq, Seq>,
      DerivingSemigroup<NonEmptySeq, Seq>
{
    public static K<NonEmptySeq, A> Wrap<A>(K<Seq, A> value)
    {
        var seq = value.As();
        return new NonEmptySeq<A>(seq[0], seq.Tail);
    }

    public static K<Seq, A> Unwrap<A>(K<NonEmptySeq, A> ma)
    {
        var neSeq = (NonEmptySeq<A>)ma;
        return neSeq.Head.Cons(neSeq.Tail);
    }
}

Anyway, I think that's enough demonstration for now. Does this seem like something worth pursuing @louthy? Like I said, I don't have direct experience with the domain wrapper monad pattern yet, but I can imagine it could be difficult getting buy-in for curious-but-FP-skeptical teams adopt said pattern, especially when there are so many other new concepts to learn with v5.

This also doesn't help at all with generating methods and special SelectMany overloads for the concrete types, but as far as I can tell code generation is basically a necessity for that.

I have most of the work for these done already on my local machine, and would be more than happy to open a pull request, or even create a separate library if I'm feeling up for that and we don't want these in Core (although like I mentioned I think they could help v5 adoption, at least somewhat)

[louthy]

This is a very interesting idea. I am certainly taking this seriously as a concept. And, if it's truly general, or at least general enough to significantly reduce the boilerplate, then I'm all for it.

This also doesn't help at all with generating methods and special SelectMany overloads for the concrete types, but as far as I can tell code generation is basically a necessity for that.

Yeah, the idea is to use source-generators. The source-generator would read the interfaces hanging off the trait-type and use that to auto-generate the non-K typed methods for the concrete type. So all of the manual typing of boilerplate should go away. I just don't want to start writing that until the core is solid (essentially I want to know where all of the pain points are before building a pain-point-reducer!)

This was also going to be my approach to reducing the boilerplate in the trait-implementation, but your idea is better in my opinion.

[micmarsh]

Thanks, glad to hear this is a route worth pursuing! Shall I open a PR to "formalize" the proposal (which I probably won't be able to do until sometime next week), or do you want to think through the idea and how it interacts with other things a little better first?

Let me know if you have any concerns or want to bounce ideas around here as well (although I likely won't be able to respond until next week here anyway)

[louthy]

I'd like to do a bit of prototyping first if you don't mind. Just want to work through the ergonomics.

If you want to push any WIP stuff for inspiration then feel free. But don't go wasting too much time, I can blitz it all once it's clear in my head.

I'm mid-refactor at the moment (streaming branch). Just trying to get all of the steaming functionality in one place and seamlessly integrated. So I might not get to this for a few days (maybe a few weeks).

[hermanda19]

+1 for this idea!

However, I think that framing these interfaces as DomanWrapper<Self, Inner> is unfortunate since it violates encapsulation.
The fact that the domain-monad-type "wraps" an underlying monad-transformer-stack is meant to be an implementation detail that consumers shouldn't rely upon. This gives you the freedom to change the stack in the future or replace it with a hand-written implementation for performance-related reasons (since transformer stacks add overhead for each layer) without requiring large amounts of churn in your codebase and I believe @louthy has written about this as an explicit benefit of using domain-monad-types before.

That being said, while the usage of monad-transformer-stack should be an implementation detail, the fact that the domain-monad-type behaves identically to the monad-transformer-stack is definitely not! Consumers of the domain-monad-type must necessarily rely on its behavior and if it happens to behave like some other monad, there's really no issue in relying on that equivalence. In fact, knowing this equivalence can aid in documenting and teaching that particular domain-monad-type.

Therefore, perhaps it would be better to frame this not as a "wrapper" but instead simply as an "equivalence"? The term that immediately comes to mind is "isomorphism" i.e. there's a lossless conversion between the two types. I could imagine rewriting your DomainWrapper<Self, Inner> interface as the following:

public interface Isomorphism<F, G>
{
    static abstract K<G, A> Transform<A>(K<F, A> fa);

    static abstract K<F, A> Transform<A>(K<G, A> ga);
}

Admittedly, this boils down to just renaming the interface and its members. However, I do think this is a better way of framing the relationship between the domain-monad-type and it's monad-transformer-stack. If you change the underlying stack of D from FT to GT but its behavior is equivalent, you can rightfully continue implementing Isomorphism<D, FT> and even add an additional Isomorphism<D, GT> implementation since the conversions are lossless. You can even hand-implement the domain-monad-type and continue implementing these interfaces since the behavior of D wouldn't have changed. Importantly, if the behavior does change, then that likely indicates a breaking change for its consumers which is exactly what a removal of these interfaces would be as well. Said another way, it can help turn breaking changes at run-time to breaking changes at compile-time (if you're diligent in keeping your interface implementations correct).

Additionally, DomainWrapper<Self, Inner> implies a one-to-one relationship between Self and Inner. On the other hand, Isomorphism<F, G> allows for one-to-many or even many-to-many isomorphic relationships between various type constructors. Thus, I can imagine a domain-monad-type implementing many DerivingFunctor<Self, Inner> (perhaps, IsoFunctor<F, G>?) interfaces and simply overriding any static abstract methods to resolve ambiguities. In other words, it provides the convenience of automatically implementing Functor methods using some other known implementation while giving you the freedom of moving to other implementations (including bespoke ones) as you need them.

[hermanda19]

I haven't fully thought it through yet. But, I wonder if there's a mechanical way of converting between a Natural<F, G> and a CoNatural<G, F> (and vice versa).

Surely we can use a generic class that delegates to the dual Transform methods?
Perhaps this isn't what you mean by "mechanical" though...
As an example:

public abstract class ContraNatural<F, G> :  //unsure about naming
    Natural<G, F>, CoNatural<G, F>
    where F : Natural<F, G>, CoNatural<F, G>
{
    public static K<F, A> Transform<A>(K<G, A> fa) =>
        F.CoTransform(fa);

    public static K<G, A> CoTransform<A>(K<F, A> fa) =>
        F.Transform(fa);
}

[louthy]

What I was thinking was it possible to get a Natural when we only have a CoNatural, or vice versa.

Imagine two generic functions:

public static class Foo
{
    static K<G, A> Bar<F, G, A>(K<F, A> fa)
        where F : Natural<F, G> =>
        F.Transform(fa);

    static K<G, A> CoBar<F, G, A>(K<F, A> fa)
        where F : CoNatural<G, F> =>
        F.CoTransform(fa);
}

One only works with Natural and one only works with CoNatural. But, the K<F, A> we have might only support one of the traits. They are equivalent though, so being able to get one from the other would allow an upfront conversion of the parameters to Bar and CoBar.

For example:

K<Arr, int> mx = Array(100, 200, 300);

var my = Bar<Arr, Iterable, int>(mx);
var mz = CoBar<Iterable, Arr, int>(mx); // FAILS

The first line compiles fine. The second line fails because Iterable doesn't support CoNatural<Arr, Iterable>. It does support Natural<Iterable, Arr> though -- which is equivalent to CoNatural<Arr, Iterable>.

My thinking was something along these lines:

// Wrapper for a type that supports Natural but not CoNatural
public readonly record struct NaturalDual<F, G, A>(K<F, A> Value) : K<NaturalDual<F, G>, A>
    where F : Natural<F, G>;

// Trait implementation for the wrapper that exposes the dual CoTransform, therefore  
// gaining support for CoNatural where we only had support for Natural before. 
public class NaturalDual<F, G> : CoNatural<G, F>
    where F : Natural<F, G>
{
    public static K<G, A> CoTransform<A>(K<F, A> fa) => 
        F.Transform(fa);
}

So, create a wrapper struct for K<F, A>, where F supports Natural<F, G>. And then make the trait implementation of that wrapper derive from the dual: CoNatural<G, F>.

Then something like this:

K<Arr, int> mx = Array(100, 200, 300);

var wrapped = new NaturalDual<Arr, Iterable, int>(mx);      
var mz = CoBar<Iterable, NaturalDual<Arr, Iterable>, int>(wrapped);

I couldn't quite get the types to line up though and it's late here now, so I'll let my subconscious work on it while I'm sleeping! My gut feeling is that there's no elegant automatic solution to this outside of trait-instances having implementations of both Natural and CoNatural for every pair of types. That's dev overhead that I don't like, but might be unavoidable.

[hermanda19]

Yeah, there really doesn't appear to be an elegant solution using a wrapper type like that...!

I was able to get your example to compile with these definitions:

K<Arr, int> mx = Array(100, 200, 300);

var wrapped = new NaturalDual<Arr, Iterable, int>(mx);
var mz = CoBar<NaturalDual<Arr, Iterable>, Iterable, int>(wrapped);

class NaturalDual<F, G> : CoNatural<G, NaturalDual<F, G>>
    where F : Natural<F, G>
{
    public static K<G, A> CoTransform<A>(K<NaturalDual<F, G>, A> fa) =>
        F.Transform(((NaturalDual<F, G, A>)fa).Value);
}

readonly record struct NaturalDual<F, G, A>(K<F, A> Value) : K<NaturalDual<F, G>, A>
    where F : Natural<F, G>;

Notably, NaturalDual<F, G> needs to implement CoNatural<G, NaturalDual<F, G>> instead of CoNatural<G, F>.

It works... But, it's pretty awkward.

The biggest problem with this NaturalDual<F, G, A> wrapper approach is that it only implements CoNatural.
If you need to call a method that requires some other higher-kinded interface, then you need to create a brand new wrapper that implements both of them. For example:

public static class Foo
{
    public static K<G, A> CoBar<F, G, A>(K<F, A> fa)
        where F : CoNatural<G, F>, Functor<F> => // NaturalDual<F, G> doesn't implement Functor<F>!
            /* Implementation */
}

All in all, this isn't very impressive.

---

I did come up with an alternative solution, though! Rather than force CoNatural<F, G> to prevent interface-unification errors, we can instead take advantage of where clauses and default interface implementations. The idea is to introduce CoTransform as a virtual method of the NaturalIso interface:

public interface NaturalIso<F, G> : Natural<F, G> // No Natural<G, F>, and so no unification error!
    where F : Natural<F, G>, Natural<G, F>
{
    // Implement CoTransform utilizing F's Natural<G, F> interface
    static virtual K<F, A> CoTransform<A>(K<G, A> ga) => F.Transform(ga); 
}

It can then be implemented completely in terms of Transform:

class F<A> : K<F, A>;
class G<A> : K<G, A>;

class G;
class F : NaturalIso<F, G>, Natural<G, F>
{
    public static K<G, A> Transform<A>(K<F, A> fa) =>
        new G<A>();
    
    public static K<F, A> Transform<A>(K<G, A> ga) =>
        new F<A>();
}

The downside of this approach is that it requires specifying both NaturalIso<F, G> and Natural<G, F> in the where clauses of any method that wishes to use NaturalIso:

static class Foo
{
    public static K<F, A> Baz<F, G, A>(K<F, A> fa)
        where F : NaturalIso<F, G>, Natural<G, F> =>
            F.CoTransform(F.Transform(fa));
}

So, perhaps it's better to "bite the bullet" and just accept the extra where bounds and exclude CoTransform altogether?

public interface NaturalIso<F, G> // Doesn't inherit any `Natural` interface.
    where F : Natural<F, G>, Natural<G, F>
{
    // Implementor promises that F and G are isomorphisms.
    // K<F, A> fa;
    // K<G, A> ga = F.Transform(fa);
    // Assert.Equals(fa, F.Transform(ga));
}

static class Foo
{
    public static K<F, A> Baz<F, G, A>(K<F, A> fa)
        where F : NaturalIso<F, G>, Natural<F, G>, Natural<G, F> =>
            F.Transform(F.Transform(fa));
}

This might be good enough since I would expect most code to only require Natural<F, G> and/or Natural<G, F> rather than NaturalIso<F, G>. The main use-case for NaturalIso<F, G> is as a base-interface for DerivingFunctor<Self, Inner>/IsoFunctor<F, G> in which case implementors don't need to specify those extra where bounds.

class F : IsoFunctor<F, G>, //implies Functor<F> and NaturalIso<F, G>
    Natural<F, G>, //required for NaturalIso<F, G>
    Natural<G, F>  //required for NaturalIso<F, G>
{
    ...
}

Thoughts?

[micmarsh]

I haven't been thinking too much about these specific type system issues, but did want to make a point about ergonomics that's slightly related your point about the main use-case; we should strongly consider retaining Deriving (or some other less general naming and implication) since the whole enterprise is primarily (at least in my mind) a workaround to not have to rely on as much code generation, and I wouldn't expect anyone should be writing actual methods that work with DerivingFunctor etc. as actual interface abstractions like they would a regular piece of business logic.

class MyAppMonad : IsoMonad<MyAppMonad, ...> could ironically be seen as allowing implementation details (the fact that the interface relies on an isomorphism for its "wrap"ing and "unwrap"ing) to bleed into the name of the user-facing interface.

[hermanda19]

I agree that we shouldn't really expect callers to rely on the DerivingMonad/IsoMonad interfaces (e.g, in where clauses or as method parameters). This is because all the relevant methods are in the Monad and Natural interfaces. The only thing IsoMonad and similar give is a guarantee to the caller that the behavior is identical to some other Monad type and to the callee a bunch of default interface implementations utilizing Transform.

However, I disagree with this statement:

class MyAppMonad : IsoMonad<MyAppMonad, ...> could ironically be seen as allowing implementation details (the fact that the interface relies on an isomorphism for its "wrap"ing and "unwrap"ing) to bleed into the name of the user-facing interface.

You can't actually conclude that MyAppMonad is relying on an isomorphism for its Monad implementation since MyAppMonad can always choose to selectively override the various Monad methods. That's just the nature of interfaces: the implementor is ultimately in control. The IsoMonad<MyAppMonad, ...> implementation shouldn't be interpreted as "MyAppMonad calls the ... type in its Monad methods" but instead "MyAppMonad has the same Monad behavior as ...". It should be perfectly valid for MyAppMonad to completely override the default interface implementations of IsoMonad<MyAppMonad, ...> and never use ... at all! The isomorphism is only used to justify the existence of the default interface implementations. This is what I was trying to get at when I advocated for NaturalIso in an earlier comment:

That being said, while the usage of monad-transformer-stack should be an implementation detail, the fact that the domain-monad-type behaves identically to the monad-transformer-stack is definitely not! Consumers of the domain-monad-type must necessarily rely on its behavior and if it happens to behave like some other monad, there's really no issue in relying on that equivalence. In fact, knowing this equivalence can aid in documenting and teaching that particular domain-monad-type.

I'd even go so far to say MyAppMonad should be able to implement IsoMonad multiple times:

public abstract class MyAppMonad : 
    IsoMonad<MyAppMonad, IO>, 
    IsoMonad<MyAppMonad, IdentityT<IO>> // IdentityT<M> is isomorphic to M; it has no effect on the monadic behavior.
{
    // overrides of Monad to ensure a most specific implementation.
}

While you wouldn't do this without a practical reason (perhaps migrating to a more-efficient monad-transformer-stack?) and you lose out on the convenience of the default interface implementations, I think it's important to consider this theoretically when it comes to the contract of these interfaces. Of course, I wouldn't recommend blocking the addition of these interfaces for these reasons! I just bring them up to help make sense of their role within the larger library.

[micmarsh]

@louthy, that sounds good, like I mentioned I don’t have much real experience with v5 overall so it makes a lot of sense for you and anyone else who’s actively utilizing it to feel things out for a while. I'll hold off on additional code contributions, especially given @hermanda19's rename proposal.

@hermanda19 Very interesting idea! My first thought was that it would be great to be able to implement that interface as public interface Isomorphism<F, G> : Natural<F, G>, Natural<G, F>, but unfortunately the compiler does not seem to allow that.

The next thing I noticed was that changing Wrap and Unwrap to Transform made the implementation of the Deriving (or Iso) interfaces much less clear, although that may be colored my my original intent and attachment to the “wrapper” idea. Compare something like

static  K<Self, B> Applicative<Self>.Apply<A, B>(K<Self, Func<A, B>> mf, K<Self, A> ma)
   => Self.Wrap(Self.Unwrap(mf).Apply(Self.Unwrap(ma)));

to

static  K<F, B> Applicative<F>.Apply<A, B>(K<F, Func<A, B>> mf, K<F, A> ma)
    => F.Transform(F.Transform(mf).Apply(F.Transform(ma)));

Again, “familiarity” is alway a tricky question because the approachability of something to others is a real factor, but I also don’t want to conflate “familiarity to me” with some kind of objective standard.

Overall I think your rename has much of the force of principle and consistency behind it, but I’m interested in seeing how if/how any discussion on the question of “familiarity” plays out.

[louthy]

So, I tried a few of the ideas from the comments above, and ended up back at the CoNatural / NaturalIso idea. Mostly to make this ergonomic for the use-case requested whilst also respecting the concept of natural-isomorphisms.

• I'm prototyping in the deriving-natural branch.
• I've created a CoNatural<F, G> type, which is the dual of Natural<F, G>.
• I've created a NaturalIso<F, G> type, which simply inherits Natural<F, G> and CoNatural<F, G>
  • I did like the idea of NaturalIso<F, G> not deriving from Natural<F, G> and Natural<G, F> (and instead constraining F and G to be Natural), this would have been awesome, except it then means usage of NaturalIso<F, G> would also enforce the manual inheritance from Natural<F, G> and Natural<G, F>, which is 3 interfaces specified. Not ergonomic.
  • NaturalIso<F, G> could inherit Natural<F, G>, which would reduce this burden to 2 interfaces being specified
    • Type : NaturalIso<F, G>, Natural<G, F>
    • Still not ergonomic
  • But, then we have to ask ourselves, what's the point of NaturalIso<F, G> if we can just write:
    • Type : Natural<F, G>, Natural<G, F>
    • That's better than:
      • Type : NaturalIso<F, G>, Natural<G, F>
      • Type : NaturalIso<F, G>, Natural<F, G>, Natural<G, F>
  • So, we either don't use NaturalIso at all, or we create CoNatural to allow for multiple inheritance of natural-transformations.
• I created a single folder in Core called Deriving
  • I created a single static partial class called Deriving
    • It has member types like Functor<Supertype, Subtype>, Applicative<Supertype, Subtype>, etc.
    • What's nice about this is we can write:
      • Deriving.Functor
      • Deriving.Applicative
      • etc.
• To make the trait implementations a bit more declarative for those who want it I have created Deriving<Supertype, Subtype> which is just an alias for NaturalIso<F, G>.

I tried this out with the Game monad in the CardGame sample.

This is the code before:

public partial class Game : 
    Monad<Game>, 
    SemigroupK<Game>,
    Stateful<Game, GameState>
{
    public static K<Game, B> Bind<A, B>(K<Game, A> ma, Func<A, K<Game, B>> f) =>
        new Game<B>(ma.As().runGame.Bind(a => f(a).As().runGame));

    public static K<Game, B> Map<A, B>(Func<A, B> f, K<Game, A> ma) => 
        new Game<B>(ma.As().runGame.Map(f));

    public static K<Game, A> Pure<A>(A value) => 
        new Game<A>(Prelude.Pure(value));

    public static K<Game, B> Apply<A, B>(K<Game, Func<A, B>> mf, K<Game, A> ma) => 
        new Game<B>(mf.As().runGame.Apply(ma.As().runGame).As());

    public static K<Game, A> Combine<A>(K<Game, A> lhs, K<Game, A> rhs) =>
        new Game<A>(lhs.As().runGame.Combine(rhs.As().runGame).As());

    public static K<Game, Unit> Put(GameState value) => 
        new Game<Unit>(StateT.put<OptionT<IO>, GameState>(value));

    public static K<Game, Unit> Modify(Func<GameState, GameState> modify) => 
        new Game<Unit>(StateT.modify<OptionT<IO>, GameState>(modify));

    public static K<Game, A> Gets<A>(Func<GameState, A> f) => 
        new Game<A>(StateT.gets<OptionT<IO>, GameState, A>(f));

    public static K<Game, A> LiftIO<A>(IO<A> ma) => 
        new Game<A>(MonadIO.liftIO<StateT<GameState, OptionT<IO>>, A>(ma).As());
}

This is the code after (using Deriving):

public partial class Game :
    Deriving<Game, StateT<GameState, OptionT<IO>>>,
    Deriving.Monad<Game, StateT<GameState, OptionT<IO>>>,
    Deriving.SemigroupK<Game, StateT<GameState, OptionT<IO>>>,
    Deriving.Stateful<Game, StateT<GameState, OptionT<IO>>, GameState>
{
    public static K<StateT<GameState, OptionT<IO>>, A> Transform<A>(K<Game, A> fa) =>
        fa.As().runGame;

    public static K<Game, A> CoTransform<A>(K<StateT<GameState, OptionT<IO>>, A> fa) => 
        new Game<A>(fa.As());
}

It's hard not to see that as an elegant solution (especially as there's no performance hit either).

Anyway, have a look, take it apart, throw any critique ...

If you're going to suggest an alternative approach (which I am open to!), please make sure the result is as elegant as the code above -- or close. If there's significantly more overhead then any new benefits become moot.

[hermanda19]

No, I don't think I can suggest something more elegant than that! 😄

My previous suggested alternatives were aimed at circumventing the need for CoTransform, but if its existence is acceptable, then I've got no complaints!

[micmarsh]

Looks great so far! I'll see if I can get to playing around with this sometime in the near future.

[micmarsh]

The game is infinite looping, looks like because the Pure implicit cast utilizes the below method, which creates a new Pure helper type;

public static Game<A> Pure<A>(A value) =>
    Prelude.Pure(value);

changing that helper method to this implementation seems to fix it

public static Game<A> Pure<A>(A value) =>
    Applicative.pure<Game, A>(value).As();

It's unfortunate that Deriving.Applicative doesn't give us the Pure method like manually implementing the trait would. Seems like an acceptable tradeoff for now, but something that could potentially be improved. I think Fail would be the only other commonly-used method that we lose this way.

[louthy]

I knew I should've checked that! 😆

[louthy]

It's unfortunate that Deriving.Applicative doesn't give us the Pure method like manually implementing the trait would.

I actually prefer that, making the trait implementation implicit (public) exposes the K<F, A> types where mostly you want concrete types. So, I like to make the trait implementations explicit (private) and use 'module functions' (i.e. static methods) to access them.

The traits methods can always be accessed either by extension methods or the static 'module methods' that belong to the trait:

• Applicative.pure<F, A>(value) and Prelude.pure<F, A>(value) both allow access to Applicative.Pure.
• Fallible.Fail is available via Fallible.fail<E, F>(value), Prelude.fail<E, F>(value),
• and Fallible.error<F>(value), Prelude.error<F>(value) for Error based Fallible types

[louthy]

Released