Hi! I have written CFP for <GHC>, using Arrow-kt. Request you all to please take few minutes to revi...

# arrow

[Gopal S Akshintala]

Hi! I have written CFP for GHC, using Arrow-kt. Request you all to please take few minutes to review and comment, in terms of technical-correctness, ambiguity, coherence. Help me improve and spread the word about Awesome Arrow. Thanks! 🙂
http://bit.ly/cfp-top

[Bob Glamm]

Heh, I saw GHC and immediately went to Glasgow Haskell Compiler

[Gopal S Akshintala]

Hehe

[Michael Marth]

Same here 😁

[Gopal S Akshintala]

Any comments @Bob Glamm and @Michael Marth ?

[Gopal S Akshintala]

I would like to send it to other Kotlin confs and FP confs as well if it makes sense

[Bob Glamm]

I read the abstract and understood the rationale, but I was confused as to why forMono and forIO were defined on RepoTC since they weren't specific to RepoTC

[Bob Glamm]

I would have expected them to be defined on adapter objects/interfaces for Mono and IO, respectively

[Bob Glamm]

The rest of it looked pretty good

[Gopal S Akshintala]

@Bob Glamm ya will probably keep them outside

[Gopal S Akshintala]

thanks!

[Gopal S Akshintala]

@Bob Glamm both forMono and forIO are dependent on Async<F> for effect{} method, so I am not able to elegantly place them outside of RepoTC<F>, unless I create another typeclass RepoUtils : Async<F> and RepoTC<F>: RepoUtils<F>, which is not so neat

[Bob Glamm]

@Gopal S Akshintala Individual functions can use effect {} via where

[Bob Glamm]

no need to use a typeclass

[Gopal S Akshintala]

Oh can you please send a sample code for the same

[Bob Glamm]

It's on arrow-kt.io somewhere, I'll need to track it back down

[Gopal S Akshintala]

Sure thanks

[simon.vergauwen]

Here is an example by @raulraja using where to restrict generics to enable syntax.

[simon.vergauwen]

https://gist.github.com/raulraja/97e2d5bf60e9d96680cf1fddcc90ee67#file-direceivers-kt

[Gopal S Akshintala]

Thanks @simon.vergauwen! I see the philosophy behind this gist is, making implicit dependencies explicit using a combination of extension functions and where and avoiding any constructor injection. Am I right? Like in direceivers.kt the below function has to declare both contexts Domain and Data to make use of the extension function getProcessedAccount()

class DefaultUI : UI {
    override fun <R> R.present(): IO<Unit> where R : Domain, R : Data =
            IO.fx {
                val account = getProcessedAccount().bind()
                !effect { println(account) }
            }
}

[Gopal S Akshintala]

@Bob Glamm for my case I think these simple extension functions outside of RepoTC<F> can get the job done, no need of where . Am I missing anything?

fun <R, F> Async<F>.forMono(thunk: suspend () -> Mono<R>) = effect { thunk().k().suspended() }
fun <R, F> Async<F>.forIO(thunk: () -> R) = effect { thunk() }

[raulraja]

yeah, the other DI technique is more for the case where you have multiple services as most OOP apps are usually structured. It gives you implicit access to all those services because you can always parameterise the entire program to a module that implements all of them through delegation. That delegation is already replaceable in tests etc.

[Bob Glamm]

@Gopal S Akshintala I don't think so. My suggestion for using where was just a result of me using Scala + Cats for the last 4-6 weeks. (F-bounded types in Scala use implicit, e.g.: def open[F[_]](path: Path)(implicit AE: ApplicativeError[F, Throwable]): F[InputStream] , which struck me as similar to where )