(unrelated) if kind is going away then how are tra...

# arrow

[Mickey Donaghy]

(unrelated) if kind is going away then how are traverse/sequence/etc. implemented in the new version?

[raulraja]

They will be projected directly over Iterable<A> for example :

fun <E, A, B> Iterable<A>.traverse(f: (A) -> Either<E, B>): Either<E, List<B>>

[raulraja]

Dropping the applicative requirement

[Mickey Donaghy]

so will every applicative have to implement it separately? (and there's no way to call it from generic code?)

[Mickey Donaghy]

and it won't be implemented for general Traverse, only for Iterable?

[raulraja]

Each data type that supports traverse, sequence etc will have it’s own but only over Iterable. In practice nobody uses other traverse instances and traverse in Kotlin for the IO cases since we have suspend is just map { effect() }

[Mickey Donaghy]

Well, I use the other instances (already Either and Option in this codebase). But understood.

[raulraja]

@Mickey Donaghy do you have some small snippet as to how you use those? It would be useful for us to determine if we can provide an alternative for it.

[Mickey Donaghy]

I mean just the usual use cases, e.g. something like

val validatedUser = myValidationApplicative.mapN(validateName(nameInput), maybePhoneInput.traverse(myValidationApplicative, validatePhone)) {name, maybePhone -> ValidUser(name, maybePhone)}

[raulraja]

There will be mapN over validated supporting that api but it will not mention Applicative, so same as that but simplified

[Mickey Donaghy]

mapN will silently work when some of the fields are optional/either?

[raulraja]

there will be a concrete mapN for Validated that is not the one on Apply as it is projected today with @extension. These concrete versions of mapN, traverse etc looks like this https://github.com/arrow-kt/arrow-core/blob/992af0866fde459725526a63e4d692bb85a969ed/arrow-core-data/src/main/kotlin/arrow/core/Validated.kt#L5[…]59

https://github.com/arrow-kt/arrow-core/blob/992af0866fde459725526a63e4d692bb85a969ed/arrow-core-data/src/main/kotlin/arrow/core/Validated.kt#L8[…]70

[Mickey Donaghy]

maybe I shouldn't have included the mapN part, I was just trying to give some context, the traverse is the part I was trying to give an example for

[raulraja]

traverse is projected over all the types that can support it but you always end up nesting a List in the result so traverse looks like Iterable<F<A>> -> F<List<A>>.
This means we can implement multiple versions of Traverse including others without the List if they are concrete but not abstract since the kind emulation would force users to call .fix() in the result. If there is a particular shape you are missing beside the abstraction ability we can look into providing it concrete.

[Mickey Donaghy]

well, Either and Validation to start with, but TBH if there's no way to abstract over it then multiple concrete implementations doesn't help that much

[raulraja]

there isn’t because Traverse is a Functor and Functor can’t be encoded without the kind emulation

[raulraja]

The kind emulation it’s painful to encode and use so it’s not something we can expect people to use until Kotlin has support for kinds or injection/cohercion in which we could automatically call fix() internally on behalf of the user, make third party types extend Kind etc.

[Mickey Donaghy]

yeah fair. Really I should just get this team to use Scala.