<@UGPMTH1D5> good question. Look here <https://kot...

# arrow

[Imran/Malic]

@Derek Berner good question. Look here https://kotlinlang.slack.com/archives/C5UPMM0A0/p1520103294000092

[Imran/Malic]

Whenever your using Reader outside of the context of Id you’ll need ReaderT. That is my digestible version.

[Imran/Malic]

And essentially local does nothing else than what it says in our API’s

[Derek Berner]

So one issue - my monad is now ReaderT<ForEitherT<ForIO, X>, D, A>

[Imran/Malic]

ok go on

[Derek Berner]

bbl.....

[Imran/Malic]

come again?

[Derek Berner]

be back later

[Imran/Malic]

BTW I recommend you to flatten your Stack and stay in your Context F without making it concrete to IO. Thereby you don’t need Reader and avoid the performance issues with all <something>T classes as ReaderT, EitherT etc.

[Imran/Malic]

But if your using top level functions a la Haskell. You do you 😎

[raulraja]

Transformers and complex transformers stack are hard to use in Kotlin because kinds are emulated and you will end up having to call fix n times as many layers

[Derek Berner]

I am finding that.

[raulraja]

also inference is not great

[Derek Berner]

I am also finding that.

[Derek Berner]

😓

[raulraja]

that is why we arebaking some of those concerns in IO

[raulraja]

including DI

[raulraja]

The Reader though is pointless in Kotlin because Kotlin has receiver functions

[raulraja]

so R.() -> IO<A> is the same as (R) -> IO<A>

[Derek Berner]

hmmmmmmmmmmmmmmmm

[raulraja]

and you can just encode:

[Derek Berner]

let me ponder and iterate

[raulraja]

fun <R>.foo(): IO<Int> where R: MyService, R: MyService2...

[raulraja]

you can use actual subtype constrains for DI in Kotlin because of delegates

[raulraja]

also IO will have facilities for environment injection