Further explanation of v5 validation example

[CoenraadS]

Hello

I was reading through the v5 blog posts, specifically the validation, but got lost on the part:

static Validation<Error, CVV> ValidateCVV(string cvv) =>
    fun<int, string, CVV>((code, _) => new CVV(code))
       .Map(ValidateInt(cvv))
       .Apply(ValidateLength(cvv, 3))
       .As();

Could someone please breakdown the fun<int, string, CVV>((code, _) => new CVV(code)) line?

My current understanding:

A function is made for currying, the first parameter <int> will be provided by ValidateInt(cvv), the second <string> by ValidateLength.

But I don't understand the third one. The CVV creation action is passed as arg to the fun? It will run on the result of the currying, when .As() is called?

[CoenraadS]

Also it's not clear how to enact on the validation result.

E.g. I was copying how I would do for an Either type:

ValidateCVV("123")
      .Match(
          ex => // why ex is string not error?
          {
              Console.WriteLine($"Error: {ex}");
              return 1;
          },
          _ => 0);

But the signatures don't match. How can I get the errors?

I looked at the sample, but it just writes the object to console: https://github.com/louthy/language-ext/blob/main/Samples/CreditCardValidation/Program.cs

[louthy]

Could someone please breakdown the fun<int, string, CVV>((code, _) => new CVV(code)) line?

You can also write it like this:

fun((int code, string _) => new CVV(code))

Which might be a bit clearer. Essentially, we're forcing C#'s type system to infer the lambda. The lambda needs to be coerced into being a Func<int, string, CVV>. The fun function does that.

It's the equivalent of:

new Func<int, string, CVV>((code, _) => new CVV(code))

My current understanding:
A function is made for currying

Correct

the first parameter will be provided by ValidateInt(cvv)

Correct

the second by ValidateLength.

Correct

But I don't understand the third one.

The third parameter is the return-type. The CVV in the fun signature is the return-type, not an argument-type. A bit like with Func<int, string, CVV>, the last type-parameter represents the return-type.

Also it's not clear how to enact on the validation result.

There are a number of ways of extracting the results. Match is certainly the primary way. But, just be aware that there are two Match overloads:

    public abstract B Match<B>(Func<A, B> Succ, Func<F, B> Fail);

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

The first one is the one that you want. The second one just fires off an Action. If you get the return-type mismatched on the Succ and Fail branches then the compiler will assume that you want the second one.

In your example, the reason why the first one isn't an error is because that's the success delegate. The second delegate is for catching the failure.

ValidateCVV("123")
      .Match(
          ex => // why ex is string not error?
          {
              Console.WriteLine($"Error: {ex}");
              return 1;
          },
          _ => 0);

It's good practice to used named parameters:

ValidateCVV("123").Match(
    Succ: cvv => 0,
    Fail: ex => 
    {
        Console.WriteLine($"Error: {ex}");
        return 1;
    });

This then looks like regular pattern-matching, is easier for others to read, and allows you to write the parameters in any order you like.

You can also use regular C# pattern-matching:

var res = ValidateCVV("123") switch
          {
              Validation.Success<Error, CVV> (var cvv) => $"Success {cvv}",
              Validation.Fail<Error, CVV> (var error)  => $"Failure {error}"
          };

I looked at the sample, but it just writes the object to console

I should probably update that!

[CoenraadS]

Thanks. I see now indeed that Validation.Match is a different signature that Either.Match. Using named args will help indeed, since left/right are swapped.

Perhaps for consistency it would make sense for Match signatures params to always go left to right?

Again thanks for detailed response.

[louthy]

Left and Right has positional meaning for Either, whereas Succ and Fail doesn't. It is much more usual to have a bigger block of code in the Succ handler than the Fail handler, which just reads better when Succ is first, so that's the reason.

Obvs with the named parameters you're free to swap if you feel algebraic data types should follow some ordering, but it's not a thing really, they're just cases in a discriminated union.

I think Either is the only type ordered like this (but don't quote me, I'm writing this from memory on my phone). Fin, Try, IO, Validation, and Eff are Succ/Fail, Option is Some/None, etc. So, really Either is the outlier -- hopefully for obvious reasons!