A modern programming language that makes developers happier.

kotlinlang

question, has anyone already written/found a retrofit converter factory for nullables into `Option`?

Nope, at least not to arrow Option, but I indeed think retrofit adapters for our data types could be something that could fit into an arrow-effects-retrofit module. Overall retrofit is one of those very used libs that could probably be prone to have its own effects

opinions <@U0B8UEMV1> <@U4UGS5FC7>?

we can have `arrow-retrofit-adapters` to provide adapters of all arrow datatypes that adhere to `AsyncContext` (soon just Async). That includes Free, Defferred, Observable, Flowable and IO at this time since those are the data types we have that can do Async.

I'm not sure an `effects` module would be in line with the current effects modules because AFAIK Retrofit does not provide it's own data types for async and concurrent computations but I may be wrong. Does Retrofit has it's own Future or Promise style data type or relies on third parties and these adapters exclusively?

No, this is a case that should be handled outside of the main Arrow repo. We can provide adapters for any MonadError easily, I’m happy to mentor whomever is interested.

Then it's just a matter of providing a single adapter for callbacks that can error with MonadError. That entire integration fits in one file. I'll be happy to help there too.

Retrofit provides Call for async requests out of the box
<https://square.github.io/retrofit/2.x/retrofit/retrofit2/Call.html>

<@U0B8UEMV1> I’ll take you up on that adapter mentorship

From what I understand, one can specify a converter factory to retrofit, and retrofit will delegate the parsing logic of the json to the converter factory, and the factory will return an instance of the data type specified for retrofit’s return type

Hmm, not exactly. There are 2 abstractions: `retrofit2.CallAdapter and `retrofit2.Converter`. Converter converts body result to specific type, CallAdapter allows to define custom container for data (like Call&lt;T&gt;, Observable&lt;T&gt; and so on). So to implement Option or any other Data Type, you should implement CallAdapter.
Or you can think about it as `F&lt;T&gt;` where `F` is CallAdapter responsibility, `T` is Converter responsibility.

thanks <@U0BRK9HC5> for the insight!. <@U0VQM95EY> if we come up with out adapters lib we should later submit a change here <https://github.com/square/retrofit/wiki/Call-Adapters> to get Arrow on the list. In this example for guava <https://github.com/square/retrofit/blob/3a9d4b77c60e3dfe3a98e0a74a59371014cad7ab/retrofit-adapters/guava/src/main/java/retrofit2/adapter/guava/GuavaCallAdapterFactory.java#L95> looks like we can easily implement this for all `MonadSuspend` since those are also `MonadError`. Our cancel semantics are still unable to actually cancel a Task. It cancels it's next binding but won't kill the task or process, just shortcircuit the computation and not sure if that is the same semantics as required by the `CallAdapter`