ChronicleT vs ValidationT

[augyg]

My question is ultimately does ChronicleT add anything above ValidationT?

For context, ChronicleT is implemented in Haskell here https://hackage.haskell.org/package/monad-chronicle-1.1/docs/Control-Monad-Chronicle.html#t:ChronicleT

I also partially ask as I wonder if this would be something I can personally contribute to language-ext as I am thoroughly enjoying using it.

My hypothesis is: yes it does, because while both are capable of accumulating errors, ValidationT returns Either a success OR a set of failures but cannot return both a success and a set of errors.

Arguably in any use case we could just keep our resultant type :: [Either a b] however this would be an enhancement to view this result as a Monad, a Bifunctor and likely more (although my knowledge of theory stops here)

[louthy]

both a success and a set of errors

Sounds like WriterT. I hadn't heard of ChronicleT tbh. So not sure what it adds over WriterT or ValidationT -- a cursory look at the source suggests a three term result (This, That, These), but I've not really looked in any depth.

I'll take a deeper look tomorrow if I can. If not, it'll probably be next week before I can respond.

[augyg]

Totally! No problem and thanks for your time always.

To add what context I can in the hope that it helps, it feels like a concise version of ExceptT e (WriterT m) a but also like a ListT in the use case I have. My particular case being I am working with the Microsoft Outlook API on a critical service for getting documents. Occasionally we get crap data and it's not clear what the code should do in response, so we track this like a warning.

(not actually in Haskell but for obvious reasons I've translated to haskell)

data JSONResult = JSONResult { results :: [FunkyData] }

transform :: [FunkyData] -> These [WeirdResult] [ValidAPIData] 

Monadic motivation for ChronicleT which is ultimately just These a b is that since we are working with a Graph API, we need to make multiple successive requests (getEmail --> getAttachments --> getAttachmentContents) so we need to have the ability to tell warnings that happen (garbage data that may just mean nothing at all)

We can represent the warning state as

These [SomeError] [SomeSuccess]

The only success state as

That [SomeSuccess]

The failure state (like either) as

This [SomeError]

I will note too that it seems that like how Writer's w arg is a Monoid, ChronicleT's c arg is also often a Monoid

I recognize that this can already be modeled with combinations of other things, so in that sense it's an enhancement but in my limited experience opinion it seems that type level solutions are preferable / it might be nice to have a more condensed monad stack.

[micmarsh]

Very interesting, clearly created by someone with a literary background!

Could also be worth implementing yourself as a learning exercise, and then either contributing or maintaining your own separate library depending on what @louthy thinks. Can't hurt to contribute to the ecosystem even if you can't to the library!

[augyg]

Thank you! @micmarsh

Here is what I have so far (DISCLOSURE: heavily helped by AI!! with my editing afterwards)

public abstract record These<A, B>;
public record This<A, B>(A Value) : These<A, B>;
public record That<A, B>(B Value) : These<A, B>;
public record These_<A, B>(A First, B Second) : These<A, B>;

public static class TheseExtensions
{
    public static T Match<A, B, T>(
        this These<A, B> these,
        Func<A, T> This,
        Func<B, T> That,
        Func<A, B, T> These)
    {
        return these switch
        {
            This<A, B> t => This(t.Value),
            That<A, B> t => That(t.Value),
            These_<A, B> t => These(t.First, t.Second),
            _ => throw new ArgumentException("Unknown These type", nameof(these))
        };
    }

    public static These<A, B> Match<A, B>(
        this These<A, B> these,
        Func<A, These<A, B>> This,
        Func<B, These<A, B>> That,
        Func<A, B, These<A, B>> These)
    {
        return these.Match(This, That, These);
    }

    // Give an error, and hold it
    public static These<A2, B> MapThis<A, B, A2>(this These<A, B> these, Func<A, A2> replace) =>
        these.Match<A, B, These<A2, B>>(
            This: a => new This<A2, B>(replace(a)),
            That: b => new That<A2, B>(b),
            These: (a, b) => new These_<A2, B>(replace(a), b)
        );

    public static These<A, B2> MapThat<A, B, B2>(this These<A, B> these, Func<B, B2> replace) =>
        these.Match<A, B, These<A, B2>>(
            This: a => new This<A, B2>(a),
            That: b => new That<A, B2>(replace(b)),
            These: (a, b) => new These_<A, B2>(a, replace(b))
        );
    public static These<A, B2> Map<A, B, B2>(this These<A, B> these, Func<B, B2> replace) => these.MapThat(replace);

    public static These<A, B> Confess<A, B>(this These<A, B> these, A newThis) where A : Semigroup<A>, Monoid<A> =>
        these.Match<A, B, These<A, B>>(
            This: a => new This<A, B>(combine(a, newThis)),
            That: b => new These_<A, B>(newThis, b),
            These: (a, b) => new These_<A, B>(combine(a, newThis), b)
        );
} 

I would love to contribute, is the ultimate idea here. I (ambitiously) thought let me contribute direct to language-ext and dug into how Either and ExceptT are written. However I am brand new to C#, coming from Haskell so I have the basics down but as I've been told by colleagues who use library and I believe the tutorials, there is a decent amount of trickery to make C# haskell-like. That said, probably best I make my own library and if this is ever worth it, then it gets upstreamed to language-ext?

In any case, I wouldn't hope to make it my own library just so that I can cut corners that would ultimately make me less useful to contributing to language-ext in the future so I was wondering the best way to understand some of the tricks that are used, for instance this source code

most notably, EitherContext

    [Pure]
    public EitherContext<L, R, Ret> Right<Ret>(Func<R, Ret> right)
    {
        return new EitherContext<L, R, Ret>(this, right);
    }

    IEnumerator IEnumerable.GetEnumerator()
    {
        return GetEnumerator();
    }

...

    [Pure]
    public IEnumerator<R> GetEnumerator()
    {
        R[] array = RightSpan().ToArray();
        for (int i = 0; i < array.Length; i++)
        {
            yield return array[i];
        }
    }

    //
    // Summary:
    //     Span of left value
    [Pure]
    public abstract ReadOnlySpan<L> LeftSpan();

    //
    // Summary:
    //     Span of right value
    [Pure]
    public abstract ReadOnlySpan<R> RightSpan();

    //
    // Summary:
    //     Project the Either into a Lst L
    //
    // Returns:
    //     If the Either is in a Left state, a Lst of L with one item. A zero length Lst
    //     L otherwise
    [Pure]
    public Lst<L> LeftToList()
    {
        return new Lst<L>(LeftSpan());
    }

[louthy]

I've created a branch to prototype the idea. I've created a These type prototype so far. It already has a problem of requiring the Semigroup trait sometimes on A, sometimes on A and B, and sometimes no requirement. That hits some of the limitations of the C# trait approach (namely that we have a single trait-implementation class implementing many traits, rather than one implementation class per trait).

This may not be a problem, but it already stops the | coalescing operator and denies the implementation of Choice. So, it could be a more problematic type to generalise.

Overall, I'm not against the idea, but my gut feeling right now is "not for v5". Because I've been trying to take a bit of time away from lang-ext to focus on other things, so adding items to the v5 release list is probably not wise.

So, perhaps take the ideas from my implementation, have a play, and as @micmarsh suggests: make a library of your own. I think there's enough here that I would be interested in it post-v5 release. And maybe if I get bored, I'll continue to have a play with the idea, but for now I think it's best I leave it for post any v5 release (officially).

[micmarsh]

In particular, the compiler complaining that in my .Fold(..) it cannot match type That with These

Without looking at or running your exact code, you're probably missing an upcast (such as (These) new That(value)) somewhere. Totally foreign concept to Haskell, but the C# compiler is sometimes bad at inferring the "inner type" of "container types" when inheritance or even interface implementation is involved.

[augyg]

ahhh yes, I was just staring at the prototype branch code, in particular this code:

    public static These<A, B> As<A, B>(this K<These<A>, B> ma) =>
        (These<A, B>)ma;

Which I'm told is casting and it looks like this is important to the higher kinded traits system?

[louthy]

@augyg

If I understand correctly, the trick is in using abstract + sealed record, then writing Match in that way.

We're simulating discriminated-unions using inheritance. sealed stops any more inheritance and abstract allows us to leverage the performance benefits of virtual-dispatch over pattern-matching. Sometimes it's more elegant too: it can make the base-type more concise and it can make the sub-type implementations clearer. Anything that works on this and has an implementation for all cases is a candidate for this 'classic OO' approach.

I believe memento is inspired by the 2000s film Memento where the main character repeats the same 10 minutes over and over again, trying to reach their objective of figuring out why, as they forget much like how the memento function forgets the successes they had if they had a fatal error xD

I mean, that's cute and everything, but it doesn't communicate that to the reader through 'osmosis', which I think all good APIs do. Not that I can think of a better name right now. But needing to watch a film or understand its premise is not a good approach to naming! ;)

All brilliant libraries

Thanks for that. I was aware of Reflex, but haven't done anything with it, I'll have read.

[louthy]

Which I'm told is casting and it looks like this is important to the higher kinded traits system?

As is downcasting from the interface K<F, A> to the concrete F<A> (which gives you access to the full interface of F<A>). Downcasting is frowned upon in OO-land, but this allows us to move between the abstract and the concrete. It's a bit of a hack to make the trait approach viable.

My judgement is that only one type (F<A>) should derive from K<F, A>. So the casting should always succeed. If you ever do anything silly like making two types derive from K<F, A> then you'll likely get a cast failed exception when calling As().

[louthy]

@augyg btw, I have just committed some changes to the branch:

• Renamed the case-type Pair to Both. It seems more in keeping with the style of naming: This, That, Both feels more 'fluid' than This, That, Pair.
• Moved the case-types (This, That, Both) into the These type (so they become These.This, These.That, and These.Both). This namespacing is consistent with Either.Left, Either.Right, and Fin.Succ, and Fin.Fail. If the type ever ends up in language-ext, it will need to be consistent.
• Added This, That, Both constructor functions to the Prelude. So, you can call them like you would Some, Left, etc.