https://kotlinlang.org logo
Join Slack
Powered by
Hi, is somewhere available the documentation for 0...
# arrow-contributors
d
Hi, is somewhere available the documentation for 0.11.0?
a
Hi there! Not yet, that’s still under construction + we only target the next version, which will be 0.10.5
s
@dnowak any specific questions on 0.11.0? The only difference you’ll find there compared to 
0.10.5
at this point is 
IO<E, A>
.
d
IO<E, A>
is the reason I wanted to play with 0.11.
s
The API of 
IO<E, A>
did not change a lot compared to 
IO<A>
. What’ll find is you’ll have 
IO.raiseError
and 
IO.raiseException
, and additional error handlers to deal with them.
👍 1
d
I wanted to use monad comprehension but got error on 
IO.fx {
- compiler has two candidate functions and does not know which one to choose. So I wanted to refer to documentation…
s
We’re currently on the verge of releasing 
0.10.5
and the work on the docs and finalizing the API will follow.
@dnowak yes that’s the biggest issue we’re still dealing with. 
Nothing
is quite pervasive throught the codebase
IO.fx<Nothing, Int>
or 
IO.fx<DomainError, Int>
is what you’re looking for
d
This works - but looks strange as I have to repeat the types in result type and then in fx call:
Copy code
fun crate(command: CreateLedgerCommand): IO<CreateError, Unit> = IO.fx<CreateError, Unit> {
s
Yes, sadly Kotlin cannot infer that. At least I don’t know a solution that could help the Kotlin compiler infer those types.
a
there’s a ticket for that, so that’s something we definitely want to try to fix
s
Kotlin should be able to infer multiple type args, no? 🤔
a
yes, but only if you provide it somewhere within the params
s
val program = IO<CreateError, Unit> = IO.fx<CreateError, Unit>
should be inferable, no?
a
the problem here is that the error might not be there, but I bet we can hack it somehow 😄
yes
d
OK, and what about this:
Copy code
val (ledger)  = getLedger(command.ledgerId)
I get error that there is no component1 function
a
it was deprecated on 0.10.5, maybe removed there
➕ 1
you should better use ! or .bind()
until arrow meta is out and we will be able to improve that 😉
s
I think it’s because there is a 
fun <A> IO.Companion.fx
overload which fixes to 
Nothing
. Maybe you need disambiguate because of that.
d
OK, I actualy liked very much the destruring call :-(
s
Yes, same here 😞 But there is a problem since Kotlin doesn’t support nested destructuring
So you cannot do 
val ((a, b, c, d)) = parTupled(fa, fb, fc, fd)
a
that + ops not executed if you ignore the variable name with 
_
😄
val (_) = IO { … }
because of kotlin optimization
s
Wait what!? really?
That sounds like a horribly dangerous optimisation 😮
a
well, depends on the point of view I guess… one could argue that destructuring a class, the same way as accessing a variable shouldn’t trigger a side effect, therefore… 🧌
d
Is there a new module? IDEA is not able to find 
.bind()
a
@dnowak can you share some of the code? at least the fx block
r
destructuring also is broken for data types like List which destructuring with componentN is not the same as monad bind
d
I just started with this:
Copy code
fun crate(command: CreateLedgerCommand): IO<CreateError, Unit> = IO.fx<CreateError, Unit> {
    val ledger  = getLedger(command.ledgerId).bind()
}
s
What is the return type of 
getLedger
?
d
Copy code
typealias GetLedger = (LedgerId) -> IO<RepositoryError, Ledger>

typealias StoreEvents = (List<Any>) -> IO<EventStoreError, Unit>
I wanted to switch to 0.11.0 as we our current system is based on 
IO<Either<E, A>>
. I hoped that Bi IO will let me get rid of EitherT , which was needed to map errors.
s
Yes, it will allow you to get rid of 
EitherT
I wouldn’t recommend using it just yet, unless you’re just curious to play with the API. In 3-4 weeks I expect the API to be more stable, and the docs to be more up to date since we’ll be actively working on that release then.
d
Ok, I’m going back to IO<Either>>
s
You cannot bind the error 
RepositoryError
to 
CreateError
unless you map the error using something like 
flatMapLeft
, 
fallbackWith
, 
handleErrorWith
or another error handler.
Or you’d have to define your error domain as.
Copy code
sealed class CreateError {
   sealed class RepositoryError : CreateError {
      //...
   }

   sealed class EventStoreError : CreateError {
      //...
   }
}
Then you should be able to bind 
RepositoryError
within 
IO.fx<CreateError, A>
There is no way for 
fx
to go from 
RepositoryError
to 
CreateError
otherwise and it doesn’t know how to 
flatMap
.
d
OK, the error that I have is:
Unresolved reference. None of the following candidates is applicable because of receiver type mismatch: public abstract suspend fun <A> Kind<IOPartialOf<CreateError> /* = Kind<ForIO, CreateError> */, TypeVariable(A)>.bind(): TypeVariable(A) defined in arrow.fx.extensions.IOSyntax
s
Yes, it’s saying it expects 
CreateError
and you’re trying to bind 
RepositoryError
which is a compilation error since the domain errors don’t align
If you rewrite to 
flatMap
you’ll see that it’s unrelated to 
bind
or 
fx
.
d
Sorry, my fault
s
No problem! 🙂 All questions and feedback on 
IO<E, A>
is very welcome since we’re still polishing the final API
So if you continue playing with it and have some feedback I’d love to hear it!
d
I would like to request 
.mapLeft
function 🙂. Simple error mapping would be easier to read:
Copy code
.flatMapLeft { e -> IO.raiseError(CreateError.Unexpected("error")) }
👌 1
s
Noted! that will be for sure added 🙂
d
Thank you
j
Doesn't 
handleErrorWith
do that? Or ist that fixed to the same 
E
? Probably wouldn't hurt inference to allow it to return a different 
E
Although the 
MonadError
-instance would then end up having different behavior so using a different operator name might be better
s
handleErrorWith
covers 
E
and 
Throwable
a
don’t we have a differentiation on handleError and handleException in this sense? although handleException might better be a left map of some sort 🤔
s
Probably best to compile a list of all names and signatures when we start working actively on `IO<E, A>`’s final API
👍 2
4 Views
Open in Slack
PreviousNext
Powered by