I would like to identify the UCs linked to the syn...

# arrow

[PhBastiani]

I would like to identify the UCs linked to the syntax inline reified in Arrow. For example, here :

inline fun <reified F> Free<ForAnkOps, ListK<File>>.run(interpreter: FunctionK<ForAnkOps, F>, MF: Monad<F>): Kind<F, ListK<File>> =
this.foldMap(interpreter, MF)

intuitively, this syntax is needed to typeclass instance look up. But how ?
I did not find this syntax described and used outside of Arrow.

[simon.vergauwen]

That looks like left over from before. That shouldn’t be necessary anymore.

[PhBastiani]

Ok, I understand this is an old Arrow syntax to be removed...
Can you explain to me (from the Kotlin point of view) how this 'pseudo impicit' worked: I did not find any reference on this tip

[simon.vergauwen]

Ah, sure. We’d add a default argument. This default argument, a function, knew which typeclass we were talking about, and which (reified) generic type we needed.

inline fun <reified F> Kind<F, A>.map(f: (A) -> B, FF: Functor<F> = functor()): Kind<F, B>

[simon.vergauwen]

Then based on reflection and naming conventions we instantiate & cache instances in a global map.

[simon.vergauwen]

The naming conventions is something that was hidden away behind code gen similarly to how @extensions works today. We had a @typeclass annotation which would generate the machinery for this trick to work.

[simon.vergauwen]

The reflection based machinery was heavy because it also needed to deal with typeclasses with multiple generics, ApplicativeError<F, E> and most of all it was error prone because it removes compile time guarantees. We attempted to make those guarantees using kapt as well but that turned out to be impossible

[simon.vergauwen]

That was also the starting point of KEEP-87

[PhBastiani]

Great, I understand now ... the current code did not allow to do this analysis. Thx Simon

[PhBastiani]

Note : this syntax also appears in the arrrow-test module.

[simon.vergauwen]

You’re welcome! 🙂 Both the arrow-test modules and arrow-free are still WIP but sadly we have to give them lower priority because of lacking man power. If you’re interested in contributing then that’d be awesome. There is a ticket for improving Free. https://github.com/arrow-kt/arrow/issues/1391

[PhBastiani]

Thx for the invitation. But, for now, I would be just a bullet ! Kotlin is not my language at work. Step by step, I hope to increase my skills of Arrow: before considering any participation, I want to use Arrow in personal projects without product consideration.