We’ve just open sourced <Quiver>, a library that extends functionality provided by Arrow. Feedback,...

# arrow

[Hugo]

We’ve just open sourced Quiver, a library that extends functionality provided by Arrow.

Feedback, issues, and pull requests welcome ❤️

[jem]

We've been using this internally since mid-2021 and finally took the time to open source it.

[stojan]

interesting

[stojan]

any reason you are not using nullable types instead of option?

[David]

It would be great to see some examples of you use quiver and the benefits of it.

[jem]

We do use nullable types in small, isolated cases. But, perhaps speaking for myself here, I appreciate the readability of a monadic type. It's valuable that both union and optional types have the same look and feel.

[jem]

Opening Quiver was the first step in hopefully opening up other libraries that use it, so hopefully we can provide examples then.

[Fred Friis]

my team also prefers Option to Kotlin's nullable types. Option is much more clear and idiomatic FP than Kotlin's kind of not great implementation of nullable types.

Granted, Option.map and flatMap and nullable type ?.let{} are functionally equivalent but the former just reads so much better, and we want not just functor and monad but applicative as well, no?

Eg given a List<Option>, we can use applicative to declaratively and with referential transparency etc etc (you know the usual FP sales pitch) turn it into an empty list if it contains a single non-populated option, or a list of Foo if all options in the list are populated.

With Kotlin nullable types I don't think you could do it as declaratively and elegantly.

Actually, even if you could, it's kind of beside the point...

To me, the point is, Option has been designed from scratch to be an FP style Maybe type with all that comes with that in terms of it being a functor, applicative functor, monad etc etc whereas while Kotlin nullable types in some ways are functionally equivalent, a nullable type doesn't implement a Functor interface, or a Monad interface, or an Applicative interface, and when it behaves like it does, it's mostly kind of by accident driven by a pragmatic need, not any real understanding of reusable, lawful FP abstractions.

(from an old thread discussin this at https://github.com/arrow-kt/arrow-core/issues/114)

[dave08]

@jem Do you have anything for the alpha versions (or the upcoming 1.2.x/2.0?), this library seems very interesting, but we're currently using the Arrow alpha... which changed a lot.

[Hugo]

@dave08 a WIP PR has been raised by @simon.vergauwen to support 1.2.0 https://github.com/cashapp/quiver/pull/26