properly now

Added video from Milan Kotlin Community Conf

if there are any maintainers around I need a green light here to release 0.7.3 https://github.com/arrow-kt/arrow/pull/989

opinions?

Reactor integration made it!

quick review here, please: https://github.com/arrow-kt/arrow/pull/1004

Done

intro-level ticket: https://github.com/arrow-kt/arrow/issues/1009

Mola

Thanks to @tomasruizlopez we have the first step on the KEEP-87 proposal where the compiler recognizes

extension

and

with

as valid syntax running on IDEA with the modified compiler. Next step resolution!

wow, that looks amazing

Is the

with(MA) { ... }

construct in the function body not superfluous? Since it is clear that the function needs to be called with a typeclass instance (

MA

) as an argument and so the instance is available/provided in the function's context for all

A

types without any additional

with(MA) { ... }

syntax?

I did not see it mentioned in the KEEP and do not have a use-case for it, but from a speculative point of view: will it be possible to have multiple type-class parameters/requirements per function?

You mean something like

fun <A> something(with Typeclass1<A>, Typeclass2<A>)

?

The reason for this is to make the syntax uniform with other language constructs like

vararg

and because it is easier to implement. Perhaps in the future we can include unnamed parameters and just one

with

to resolve all typeclass instances.

👋 Inspired with your talk on kotlinconf, decided to try to contribute a few in arrow. I want to start from https://github.com/arrow-kt/arrow/issues/729. Is it still actual issue? Also, watched the semigroup laws - they seem to be outdated. Any issue about that?

Folks, I would like to upload the code for the Retrofit plugin for Arrow. What do you believe it is better: Create a separated repository or a package inside effects or a package for integrations?

@Leandro Borges Ferreira what data types and type class instances are provided in that integration?

There's no new type classes or data types. The adapter let you to use IO or any kind of Async<F> as a response in the Retrofit client interface. Like this:

interface ApiClient {
@GET("search/repositories")
    fun getRepositoriesIO(@Query("q") language: String,
                          @Query("sort") order: String,
                          @Query("page") page: Int): IO<GithubAnswerDto>
}

Same idea from RxJava2CallAdapterFactory for Retrofit

I see, in that case we should create a new submodule at the same level as

core

called something like

integrations/retrofit

. Is it possible to also define an endpoint in a polymorphic way? Thinking in something like:

class ApiClient<F>(async: Async<F>) : Async<F> by async {
    @GET("search/repositories")
    fun getRepositories(
                          @Query("q") language: String,
                          @Query("sort") order: String,
                          @Query("page") page: Int): Kind<F, GithubAnswerDto>
}

or

interface ApiClient {
    @GET("search/repositories")
    fun <F> getRepositoriesIO(@Query("q") language: String,
                          @Query("sort") order: String,
                          @Query("page") page: Int): Kind<F, GithubAnswerDto> 
}

?

It already supports that. Like this:

@GET("search/repositories")
    fun getRepositoriesEffect(@Query("q") language: String,
                              @Query("sort") order: String,
                              @Query("page") page: Int): CallK<GithubAnswerDto>

We tried with Kind<F, GithubAnswerDto>, but the Response cannot have Parametrized types

sounds good, thanks, even just having IO allows us to go back to F if needed, was just curious. Ideally we'd put this in a separate repo but we want these integrations to build with arrow as we approach 1.0. so having it as a new module group similar to

core

called

integrations

would work better until we reach 1.0.0

Ok, I will open the PR then

thanks!

no problem =]