We ve just open sourced

Question

We ve just open sourced <https github com cashapp quiver tree main|Quiver> a library that extends functionality provided by Arrow Feedback issues and pull requests welcome heart

jem · Answer

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

stojan · Answer

interesting

stojan · Answer

any reason you are not using nullable types instead of option

David · Answer

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

jem · Answer

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 · Answer

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

Fred Friis · Answer

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 lt Option gt 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 · Answer

< 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 · Answer

< dave08> a WIP PR has been raised by < simon vergauwen> to support 1 2 0

simon.vergauwen · Answer

I am personally surprised by the heavy use of Option but I ve recently also encountered some issues due to nested null in generic code sweat smile It even resulted in me making 2 bug fixes against them in Quiver I m looking forward to working together with the Quiver team to facilitate all usages so that we can solve everyones needs together for FP in Kotlin To that end I d love to get feedback on my questions and remarks in < Hugo> Also we plan to release 1 2 0 RC at the end of this week with the final deprecations to 2 0 0 It will be more clear in the deprecation message and in the release post but I am inviting all of you already to check it out or do so on an alpha versions and let us know if any of the APIs critical to you are being deprecated So we can consider moving them to Quiver or can keep move them in Arrow core if the community consider them core to fp in kotlin The release post wil also explain the rationale of why some APIs are being deprecated We care about the success of functional programming in Kotlin and is also why we kept `Option` around when it was originally marked for deprecation pre 1 0 0 Thanks to a discussion started by < mitch> at the time pray Thanks in advance all for your support of Arrow and FP in Kotlin heart kotlin intensifies purple arrow intensifies