Arrow: Safe zipping using Ior

[1Jajen1]

I read a bit about, and used, these in a small project lately and it's a nice improvement over the usual zipping operators.

In arrow Ior is isomorphic to These from haskell and as far as I can tell also implements the typeclasses the same way.

Given that Ior already exists the missing parts are:

• Align typeclass and instances Done in #1809 (Thanks @abendt )
• Semialign typeclass and instances Done in #1800 (Thanks @abendt )
• Unalign typeclass and instances
• Zip/Repeat/Unzip typeclasses and instances
• Crosswalk/Bicrosswalk typeclasses and instaces

I'd be fine with skipping Crosswalk, but the others would be quite useful.

[abendt]

@1Jajen1 i also started to look at the Crosswalk implementation and have difficulties to understand the laws definition: crosswalk (const nil) = const nil (http://hackage.haskell.org/package/semialign-1.1/docs/Data-Crosswalk.html#v:crosswalk)

i interpret the types like this

left side:
const nil : a -> f b
crosswalk (const nil) : t a -> f (t b)

right side:
const nil : a -> fb

as these types do not seem to match i am most likely misunderstanding somthing here. can you help me understand this law and how the kotlin version should look?

forAll(G) { a: Kind<T, A> ->
 val constNil: (A) -> Kind<F, B> = { _: A -> ALIGN.empty<B>() }
    val ls: (Kind<T, A>) -> Kind<F, Kind<T, B>> = { ta: Kind<T, A> -> crosswalk(ALIGN, constNil, ta) }
    val rs: (Kind<T, A>) -> Kind<F, Kind<T, B>> = constNil // wrong type here!

    ls(a).equalUnderTheLaw(rs(a), EQ)
}

[1Jajen1]

Your types are correct, it becomes a bit easier with explicit foralls:
nil: forall b . f b
const nil : forall a, b . a -> f b.
LHS: crosswalk (const nil) : t a -> f (t b) foralls don't matter here for the law anymore
RHS: const nil : forall a, b . a -> f b == t a -> f (t b) here foralls make the difference as forall a includes t a (not the same a!) and similar for b and t b

[abendt]

thanks, clears some bits up but still trying to wrap my mind around it :-)
i still struggle to get the kotlin code. in this version the types match but i honestly don't understand if it makes sense

[1Jajen1]

You cannot define for all like code in kotlin. That's why you can't define constNil like that. Also skip the partial application, its again point free code that makes it confusing: crosswalk (const nil) xs == nil that is exactly the same thing. If you twist the types enough you will figure that out :)

[abendt]

ok, i read a bit about haskells forall and it makes sense why my first approach didn't work.
i understand the haskell definition says: for any a return f b. this includes when a actually is t a in which case the result will be a f (t b). the constNil function in my example is not that flexible as it can just be used on "simple" a not on t b
if i still wanted to have a named constNil function in my example i would need to define two:

• val constNil1: (A) -> Kind<F, B>
• val constNil2: (Kind<T, A>) -> Kind<F, Kind<F, B>>

so i can get rid of the named function:

 val ls: (Kind<T, A>) -> Kind<F, Kind<T, B>> = { ta -> crosswalk(ALIGN, { ALIGN.empty<B>()}, ta) }
 val rs: (Kind<T, A>) -> Kind<F, Kind<T, B>> = { ALIGN.empty() }

is that correct?

[1Jajen1]

That should work. In an actual implementation I'd skip partial application (it just does not really work as nicely in kotlin) tho.

[abendt]

prepared the Crosswalk/Bicrosswalk stuff now too :-)

[abendt]

i noticed there are some more functions that build on top of Semialign: Specialized Aligns http://hackage.haskell.org/package/semialign-1.1/docs/Data-Semialign.html#g:2

would it make sense to also implement them in arrow?

[1Jajen1]

everything except the vector one. Just add salign and padZip to Semialign and the list ones to ListK, guess padding lists and semigroup combine are the most common cases

[abendt]

everything except the vector one. Just add salign and padZip to Semialign and the list ones to ListK, guess padding lists and semigroup combine are the most common cases

ok, will create an extra PR then

question is how to add the functions to ListK. i don't think the functions could go directly to ListK. the functions require the ListK.semialign instance. The class ListK lives in arrow-core-data, the ListK semialign instance is defined in arrow-core. So it seems ListK cannot use ListK.semialign() directly.

alternatives is see:

• defining some extension functions in arrow-coree.g. fun <A, B, C> ListK<A>.lpadZipWith(...) = ListK.semialign().run {...}
• adding the functions to the ListK.semialign instance

[1Jajen1]

The last bit of this was just finished in #1820 . Thanks @abendt for taking this on!