I can’t find Reader and ReaderApi in arrow 0.10.3,...

# arrow

[Francesco megna]

I can’t find Reader and ReaderApi in arrow 0.10.3, where is it? 🤯

[Jannis]

Latest master (don't think mtl has changed since 0.10.3) has it in arrow-mtl and more specifically in this file: https://github.com/arrow-kt/arrow/blob/master/modules/mtl/arrow-mtl-data/src/main/kotlin/arrow/mtl/Reader.kt

[Francesco megna]

Oh thx, what is mtl?

[raulraja]

MTL is where the monad transformers and their type classes are including Reader which is an alias for Kleisli

[Jannis]

mtl is short hand for monad transformer library which is what it is called in haskell from where this pattern originated. mtl usually spans monad transformers and typeclasses associated with those. The purpose of transfomers is the change the behaviour of some monad to add on some other behaviour. For example Reader is a typealias for Kleisli Id which can be translated as "extend Id with Reader abilities"

[raulraja]

it’s still an experimental library since we plan on assimilating some of those features with other techniques that are more ergonomic in Kotlin

[raulraja]

The reader monad for example offers no benefit over extension functions unless you are doing polymorphism

[Francesco megna]

I'm trying to use them for my UseCase, something like

class UseCase { 
 fun exec(): Reader<Repository, List<User>>
}

[Francesco megna]

it's less ergonomic than pass Repository via constructor, propably i only use for stay "functional"

[Jannis]

I think the benefit of the Reader pattern only really comes into play when you have multiple functions that need the provided context and/or you want to provide the same context throughout your function hierarchy (For example readers are great to replace DI, which when done with generated sources is just plain awful imo). Using a reader just to pass an additional parameter to a single function is far worse than simply having an additional parameter.

[raulraja]

@Francesco megna also in that case you may just want to use a val since a Reader is already a function

[Francesco megna]

My things is to create many UseCase with different configuration, so make DI with Reader, probably is only a style excercise

[raulraja]

I guess what I’m saying that all that is the same as a top level function:

fun Repository.users(): List<User>

[raulraja]

which is also probably leaner allocations wise