New to Arrow, I'm experimenting using it to replac...

# arrow

[Neil]

New to Arrow, I'm experimenting using it to replace Exceptions. Nothing async. I've a few functions that return Either<> that are called in series by a function that also returns either. If one of the called functions returns Left is there a neat way for the parent to immediately abort and return that Left?

[Attila Domokos]

I gave a talk recently on better error handling with Arrow. Check out how neatly you can call a chain of functions that return an Either: https://github.com/adomokos/kotlin-sandbox/blob/master/src/main/kotlin/sandbox/github/explorer/EitherApp.kt#L64-L68

[Attila Domokos]

If the deserializeData returns Left the call chain will return that Left value.

[Neil]

Thanks. That's neat if everything is chained using .map{}, but that adds quite a lot of boilerplate around each function call.

[Attila Domokos]

Well, context free function is invoked with map , monadic functions are invoked with flatMap.

[thanerian]

old but gold https://www.slideshare.net/ScottWlaschin/railway-oriented-programming

[thanerian]

chaining dependant operation should use flatMap not map

[Bob Glamm]

☝️

[Bob Glamm]

and the boilerplate will be greatly reduced when using the comprehension syntax

[Neil]

Ok. Still though you need that boilerplate around each function call.

[Attila Domokos]

If you look at the example I showed you, the individual functions are returning Either values, or just operate on functions without the Either context. I am not sure that is more boilerplate than doing try/catch calls in functions.

[Bob Glamm]

E.g. something like the following is actually a chain of .flatMap in the fx block

fun f1(...): Either<Throwable, Int> = ...
fun f2(x: Int): Either<Throwable, String> = ...
fun f3(y: String): Either<Throwable, Boolean> = ...

Either.fx<Throwable, Boolean> {
    val (a) = f1(...)
    val (b) = f2(a)
    val (c) = f3(b)
    c
}

[Jannis]

that is equal to f1().flatMap(f2).flatMap(f3) isn't it? fx doesn't always make code cleaner

[Bob Glamm]

Yes. Depends on the situation, I think

[Neil]

@Attila Domokos same here, each function returns an Either. So I need to chain them and individually wrap each one in flatMap() or map() as in your example to have the later ones abort if the first returns Left.
But when throwing an Exception I would just have one try/catch block wrapping the whole series.

[Bob Glamm]

Normally exception handling is handled by IO, not Either

[Bob Glamm]

and with IO the boilerplate is still overall less than a top-level `try`/`catch`

[Bob Glamm]

plus nifty combinators like attempt and handleErrorWith are available to deal with error conditions

[Bob Glamm]

also resource safety with Bracket and Resource

[Bob Glamm]

in particular, Bracket with `try`/`catch` only is very difficult to write

[Neil]

@Bob Glamm thanks, so fx{} aborts if anything returns a Left? That would do what I want... but it looks like I need to assign a var to the return of every function to trigger that?

[Jannis]

Handling exceptions with Either is fine. Catching them is not something Either should be used to do. IO is much nicer in that regard because you can define handlers at very specific levels, it automatically catches exceptions and is pure code.

[Bob Glamm]

Yes, the val (...) = expr syntax de-sugars to repeated flatMap

[Bob Glamm]

I think for your specific code Jannis is correct, f1.flatMap(f2).flatMap(f3) is cleaner

[Neil]

ah ok. Some functions just return Unit on the Right, so I'm doing a wasted assign.

[Bob Glamm]

Use ! or .bind()

[Neil]

but writing flatmap() lots of times is quite verbose/boilerplate-y for sync code.

[Bob Glamm]

e.g. if f2 above returned Unit then !f2(a) instead of val (b) = f2(a)

[Bob Glamm]

if it's lots of times then it's more likely to use fx comprehensions

[Bob Glamm]

in my experience the value of types with flatMap far outweighs the (currently) somewhat unusual syntax

[Bob Glamm]

but (IMO) that becomes more obvious when using IO

[Attila Domokos]

flatMap can be noisy when your coming from Haskell, but like @Bob Glamm mentions it, there is quite a bit of functionality you can rely on.

[Neil]

I'm coming from Java and finding it much noisier than Exceptions 🙂

[Jannis]

It's a cleaner pattern though. It makes exception paths explicit. Though if you end up wrapping literally everything in Either you kind of loose the benefits^^ Also using Throwable in left is kind of sub-par. A more explicit type might be better

[Neil]

@Bob Glamm ah sorry the function doesn't return Unit, it returns Either<MyDomainError, Unit>. Compiler likes val ignoreme = f2(a) but not !f2(a)

Or should I look at IO instead?

[Bob Glamm]

Could be f2(a).bind() instead of !f2(a). Sorry, it's been a couple of months since I've used Arrow

[Jannis]

You cannot mix Either<L1, A> and Either<L2> btw, Either only composes if the left is the same.

[Bob Glamm]

I tend to just use IO for operations that yield traditional side-effects: e.g. opening/reading from a file, read/write database, HTTP endpoints, etc.

[Bob Glamm]

I would use Either in cases like signature verification or decryption - things that can fail but aren't necessarily a traditional side-effect

[Bob Glamm]

(although in the latter case I get lazy and just use MonadError anyway)

[Neil]

Yes the Errors are my own domain model hierarchy, not extending Exception.

[Jannis]

(although in the latter case I get lazy and just use MonadError anyway)

With polymorphic F or of a fixed type? Because that usually leads to mtl style later? o.O

[Bob Glamm]

polymorphic F

[Jannis]

bind is only available inside fx and only for the correct `L`: Either.fx<L, R> only provides Either<L, *>.bind()

[Neil]

Yes, from reading IO it does seem to be about async things and at the moment everything in our codebase is very much sync.

[Bob Glamm]

IO handles sync and async

[Bob Glamm]

Let me see if I can find the relevant typeclass diagram

[Neil]

ah, ! works, interesting, will have to find what that is...

[Bob Glamm]

sadface, the typeclass diagrams are missing from arrow-kt.io 😞

[Bob Glamm]

Anyway, traditionally IO has a number of typeclass instances, so it handles Async, Sync, Monad*, Applicative*, etc.

[Jannis]

IO in arrow has a few purposes:
• It defers computation (and thus makes it lazy and pure) Good for referential transparenty and thus easy refractoring
• It provides powerful methods of handling errors/exceptions with resource safety
• It provides easy methods to run code concurrently (and keeping the guarantees from errors handling over async bounds)
It is generally a good idea to use it if your program involves side-effects and you may want to go async at some point. For error handling stick to what @Bob Glamm referred to above: IO for code you don't own and that involves side-effects (like throwing) and a different exception type for error paths in pure code (like Option, Either)

[Jannis]

@Bob Glamm sync is a scala cats thing afaik. We named it MonadDefer for some reason^^

[Bob Glamm]

So if your functions are synchronous:

def f1(...): Kind<ForIO, Int> = ...
def f2(...): Kind<ForIO, String> = ...

IO.fx { 
  val (a) = f1(...)
  val (b) = f2(a)
  b
}

[Bob Glamm]

@Jannis ahh. I've been bouncing between Arrow & Cats in order to try to expand my understanding

[Bob Glamm]

I'm currently in Cats land

[Neil]

Is there a way to build the .bind() into f2() so that the caller doesn't have to assign to an unused var or ! or .bind() ?

[Bob Glamm]

Building it into f2() means evaluating the effect eagerly instead of lazily

[Bob Glamm]

Think of it this way: using an fx block is constructing a program that will be executed later within the given effect (Either, IO)

[Bob Glamm]

The functions will not be called until you run the program, e.g. with .fold (for Either) or something like .unsafeRunSync (for IO)

[Bob Glamm]

That's intentional so that effects occur at the program boundary. Everything else is referentially transparent so you can (for instance) pass that program around and use it as freely as you'd like

[Jannis]

It is not a problem to "build" it in as long as it is in an fx block. But that is hard to do in arrow atm

[Neil]

this is all sync code, it will all be run immediately anyway.

[Neil]

hmm I guess f2 doesn't know it is within an fx block.

[Neil]

I'm concerned it's easy to forget to ! or .bind() .

[Bob Glamm]

.. darn, there used to be a really good example on arrow-kt.io of functions as values vs. code that is just executed

[Jannis]

It would be an antipattern to explicitly add that autobinding manually. With arrow-meta I proposed that:

fx {
  val fa: IO<A> = ...
  val x by fa // binds
  fa // also binds
}

Is valid syntax. This means forgetting ! bind is not a problem.
Right now you are correct, it is easy to forget

[Jannis]

Haskell does that as well. In do blocks it binds automatically

[Attila Domokos]

well, you need to use <- to do it.

[Jannis]

do
  let fa :: IO a = ...
  x <- fa -- binds
  fa -- binds

[Bob Glamm]

Ok, regarding "this is all sync code, it runs immediately anyway": there is a distinction that needs to be made

[Bob Glamm]

and that distinction is between composition of programs and effects. vs actual execution of everything

[Bob Glamm]

Using fx and lazy evaluation results in "programs" (and by programs, I mean small sets of function call chains) that can be chained/attached together easily

[Bob Glamm]

Taking a synchronous (runs immediately) application and translating it to use IO will still result in the application running immediately and synchronously, but the composition of functions inside the application and their evaluation is lazy instead of eager

[Bob Glamm]

e.g. the IO.fx {} example ^^ up there composes all of the functions together, and that whole block would be run synchronously and immediately upon calling .unsafeRunSync on the whole thing

[Bob Glamm]

but none of the functions are evaluated (lazy) until .unsafeRunSync

[Neil]

Thanks. I think that makes sense, similar to Rx's Observable chain.

But all I'm after at the moment is a clean replacement for Exceptions 🙂

[Neil]

I think that's a common thing, given all the blog posts that direct us checked-Exception-refugees to Arrow.

[Jannis]

For just exceptions and nothing else Either will work just fine. Just remember how to compose them map, flatMap, traverse, mapN, fx will be your most useful methods. Also use domain errors and stay away from wrapping everything regardless of need in Either. Then it will be a good replacement. If you want to use IO later on you will get a nice 1-1 mapping with IO<E, A> as soon as we start releasing 0.11 snapshots, which is planned right after the next release

[Neil]

Yes I read the blog post that mentioned BIO, sounds like it will be useful to us.

[Neil]

I think wrapping each function call in map/flatmap/traverse etc operators is quite a lot of boilerplate compared to one catch block at the bottom.

[Neil]

I like the sound of IO helping with exception handling but I don't want to have to convert all code to .map/.flatMap style.

[Bob Glamm]

My strategies have been to convert incrementally

[Bob Glamm]

a) provide functionality as a library that can be called from existing non-Arrow code, or

[Bob Glamm]

b) provide "programs in Either" or "programs in IO" that can be called with .fold or .unsafeRunSync that can be called at well-defined boundaries within try/catch

[Neil]

ah, does .fold run on IO and cause execution like .unsafeRunSync does?

[Bob Glamm]

.fold runs on Either

[Bob Glamm]

.unsafeRunSync runs on IO

[Bob Glamm]

but yes, they both force evaluation

[Bob Glamm]

Either also has methods like getOrElse and getOrHandle that also force evaluation

[Neil]

Thanks.
I like fold{} as it gives a clear place to handle error vs success, and fx{} as it provides a way to abort the block when anything returns a Left.

[Bob Glamm]

In general the data types / typeclasses provided by Arrow all include clear places to handle errors vs. success and ways of short-circuiting computation in the face of errors

[Bob Glamm]

it's one of the big benefits IME

[Neil]

...if you're using it in the way it's intended - functionally - yes. Trying to squeeze it into imperative code whilst keeping that code imperative breaks the neatness somewhat.

[Neil]

The risk of forgetting to .bind() or ! or is concerning me :-(

[Jannis]

it's bad, only thing that can stop that atm is code-review. It is a solved problem with arrow-meta comprehensions which will be in arrow very soon (afaik the plan is late this month or next month, but no promises^^)

[Neil]

cool, I'll keep a look out 🙂

Thanks very much everyone for your help.

[Mike]

It's not often you forget the ! or bind as the returned type will be an Either if you forget it, and therefore not directly usable by the next statement.

Although it's more code, I prefer the explicitness of Either and custom error codes. The caller knows something can go wrong, and can decide how to handle it, or let it 'bubble' up. Exceptions still exist for truly exceptional, nothing the caller can do about it, situations.

I like to think of Either as 'checked exceptions implemented in a usable, harder to abuse manner'