Currying error on the wrong side

This story tracks back to the first release of F# where the function Async.Catch was added, using the type on the left for the “right” value.

This in a type system with HKT support is the wrong decision, as we’re interested in currying types, then we want to have the good value on the rightmost position.

Now, in F# land we don’t have real HKTs so that’s not a technical restriction, just theorotical at the moment.

So, people started adopting it, then the new Result type landed in F# and guess what? They did it again. Left type for the right type.

Now, people is asking for some Result functions added to F# core. This is when the problem becomes a real problem, because here we’re not talking about types, we’re talking about actual values.

For values, it’s fair to think that’s also convenient to curry on the good one. See this comment from @kspeakman https://github.com/fsharp/fslang-suggestions/issues/526#issuecomment-393539604

Now the problem is we still don’t know what would be the standard for F# it’s probably a bit early. Here in F#+ we did the either function with the error on the right, we can change it in V2 but now we’re about to ship bifoldables, so the question is do we want to swap the functions? If the answer is yes, we can still do it for v1.1 but not later.

[wallymathieu]

Sounds like the logical choice then is to document the weirdness and live with it. It’s a bit of an ugly remnant, but what to do.

[gusty]

as usually compiler helps you out with which if 'a and which is 'b.

Yes. But I would say this problem becomes important when writing generic code.

Let’s try to draft some consistency rules:

• We assume Choice and Either types to have their types reversed.
• When we create a fake HKT for an abstraction we put the arguments in the correct order.
• Therefore, a Bifoldable<'T1,'T2> correspond to Choice<'T2,'T1> and Result<'T2,'T1>.
• Also, Bifunctor should follow the same rules, but we’re a bit late as that would be a breaking change. Indeed this reveals that our bimap for Result is reversed, normally the first function maps on the Error.
• Bifunctor and Bifoldable should be consistent as there are some rules involving both.
• ArrowChoice is also affected, it looks like it is already reversed but I would say it needs to be reviewed.
• All these changes would impact Lens.

We’re a bit late now, either we:

1. Do reverse Bifoldable, it would be out of sync with other abstractions that will be corrected in v2.0
2. Leave Bifoldable consistent with the existing abstractions. Eventually for v2.0 all will be swapped.
3. We don’t add Bifoldable until v2.0 to avoid conflict.
4. We do add Bifoldable but not the instances for Either and Choice which are the conflicting ones.

Thoughts?